WORLD INTELLECTUAL PROPERTY ORGANIZATION 
International Bureau 




PCT 

INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(51) International Patent Classification 6 : 
G06F 17/60, 15/46, G06K 5/00 



Al 



(11) International Publication Number: 
(43) International Publication Date: 



WO 99/33016 

1 July 1999(01.07.99) 



(21) International Application Number: PCT/US98/27496 

(22) International Filing Date: 22 December 1998 (22.12.98) 



(30) Priority Data: 
08/995,591 



22 December 1 997 (22. 1 2.97) US 



(71)(72) Applicant and Inventor: WONG, Charles [US/US]; 
14250 Miranda Road, Los Altos Hills, CA 94022 (US). 

(74) Agents: URE, Michael. J. et al.; Burns, Doane, Swecker & 
Mathis, L.L.P., P.O. Box 1404, Alexandria, VA 22313-1404 
(US). 



(81) Designated States: AL, AM, AT, AU, AZ, BA, BB, BG, BR, 
BY, CA, CH, CN, CU, CZ, DE, DK, EE, ES, FI, GB, GE, 
GH, GM, HR, HU, ID, IL, IS, JP, KE, KG, KP, KR, KZ, 
LC, LK, LR, LS, LT, LU, LV, MD, MG, MK, MN, MW, 
MX, NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, 
TJ, TM, TO, IT, UA, UG, US, UZ, VN, YU, ZW, ARIPO 
patent (GH, GM, KE, LS, MW, SD, SZ, UG, ZW), Eurasian 
patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European 
patent (AT, BE, CH, CY, DE, DK, ES, FI, FR. GB, GR, 
IE, IT, LU, MC, NL, PT, SE), OAPI patent (BF, BJ, CF, 
CG, CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG). 



Published 

With international search report. 



(54) Title: INTEGRATED BUSINESS-TO-BUSINESS WEB COMMERCE AND BUSINESS AUTOMATION SYSTEM 



External 




(57) Abstract 

The present invention, generally speaking, provides software that enables end-to-end, business-to-business Web commerce (Web 
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INTEGRATED BUSINESS-TO-BUSINESS WEB COMMERCE AND BUSI- 
NESS AUTOMATION SYSTEM 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to business-to-business Web commerce and 

to business automation systems. 

2. State of the Art 

Web commerce may be defined as the use of a computer network, such as 

the Internet, to do business, such as buy and sell products or services. Although 
Web commerce is still in its infancy, relatively speaking, Web commerce is pre- 
dicted by some to soon become the dominant mode of business practice. Web 
commerce allows business to move much more quickly, without the burden and 
cost of paperwork. 

Despite the promise of Web commerce, current Web commerce software is 
typically of very limited capability. Most Web commerce is consumer-oriented 
rather than business-oriented. The tacit assumption is that the purpose of the Inter- 
net should be to enrich people's personal lives more than to enable business to 
move at light speed. Furthermore, typically each transaction is treated in isolation. 
No on-going course of business is assumed or facilitated. 

Material management functions such as procurement represent a substan- 
tial expense and burden for medium and large businesses. Purchases are typically 
subject to approval at multiple levels. In the case of the purchase of a computer, for 
example, an employee might submit a purchase request to the employee's supervi- 
sor, who might approve the request and forward it to the MIS (Management Infor- 
mation Systems) department, which might approve the request and forward it to 
accounting for budgetary approval. The real cost of such a process is estimated to 
be as much as $100 per purchase request. Furthermore, the time required for such a 
process to be completed may be weeks or months. In the meantime, productivity 
may suffer. 
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Purchasing, moreover, is only part of the larger problem of material man- 
agement. Once materials have been procured, typically they must be tagged, 
tracked and accounted for, both physically and in accounting terms such as depre- 
ciation, etc. The latter activities may either be conducted in an organized fashion, 
often at considerable expense, or haphazardly, with marginal effectiveness. 

Existing Web commerce software is likewise fraught with problems for the 
selling company. When an order is placed through the Web, it typically results in a 
fax or email, information from which must be manually entered into an internal 
sales system that may or may not be linked to other closed systems such as 
accounting, human resources, purchasing, assembly, etc. Even if these various sys- 
tems are linked in some fashion, such linking is fixed, not responsive to change. 
Hence, once an entry is made, depending on the degree of automation, additional 
manual intervention may be required to achieve the desired final result, e.g., ship a 
product to a customer. The purchaser is typically unable to determine the status of 
an order without placing a call or sending an email. Moreover, order fulfillment is 
again only a part of the larger problem of total customer satisfaction (which is in 
turn only a part of the larger problem of running a successful, profitable business). 
Returns are bound to occur and must typically be handled manually, typically by a 
Return Merchandise Authorization (RMA) or traffic department. Also, some frac- 
tion of shipments are bound to be lost, damaged or mis-shipped. Related insurance 
claims typically must also be handled manually both by the traffic and accounting 
departments. Even though the foregoing activities are closely related functionally, 
the mechanisms for handling these activities, whether manual or automated, are 
often ad hoc, because of the unanticipated, non-routine, but inevitable nature of 
such events. 

On a business-wide scale, the same is largely true: the various activities of 
the business, while they may be separately automated, are not automated in a uni- 
fied, synergistic fashion. Automation is typically performed by automating, testing 
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and implementing fixed, linear work flows for a fixed environment, resulting in 
systems that are not adaptable to the real, changing business environment. Most 
often, different departments each have separate database systems with the depart- 
ments being linked by a local- or wide-area network. A person in one department 
obtains information from a different department by sending an email and request- 
ing a report. Referring more particularly to Figure 1, in accordance with a typical 
model of business automation, various departments (e.g., sales, sales support, cus- 
tomer service, accounting, purchasing, receiving, engineering, assembly, shipping) 
are separately automated but linked together by a computer network (e.g, LAN, 
WAN). Each department interfaces to multiple different departments in an essen- 
tially manual fashion but using modern electronic communications tools — phone, 
fax, email, computer hardcopy, etc. Comparison of the resulting overall business 
process to a Rube Goldberg invention is apt, if mildly exaggerated. The process 
entails repeated transmission of duplicate information to different departments and 
repeated transmission of additional information and instructions to different 
departments on an as-needed basis. The party transmitting the information controls 
the amount and quality of information conveyed. The party receiving the informa- 
tion has no control over the information or the quality of the instructions received 
but rather is entirely dependent on the party transmitting the information. Duplica- 
tion occurs both within departments and between departments. An external influ- 
ence to the system (a call from a customer or vendor, a new customer account, a 
ruffled employee) can and often does cause a flurry of activities, but often pro- 
duces less-than-commensurate positive results because of the inherent inefficiency 
of the system. The process, because it is ill-defined, is not easily reversible when 
an error has been made. In most systems, mistakes must be propagated to the end 
of a work flow before reversal can occur. 

The foregoing model results in the fragmentation of information— "the 
right hand does not know what the left hand is doing." Information is transported 
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from one place to another, either in hardcopy form, necessitating re-entry, or in 
such electronic form as to require substantial massaging, and with substantial 
latency such that by the time the information is to be used it is already outdated. A 
business executive, for lack of readily-available, accurate, verifiable information 
in usable form, must then rely heavily on subordinates to obtain a picture (hope- 
fully accurate) of what is happening inside the company. Considerably employee 
time may be spent gathering historical data to satisfy the need for management 
information. The same factors that hamper management performance may also 
cause performance at lower levels within the company to suffer. Employees may 
lack timely information regarding critical tasks that need to be performed. For lack 
of timely information regarding returns, for example, or some other aspects of 
operations, accounting personnel may pay invoices that should in fact not be paid. 

The lack of readily-available, verifiable information in usable form is most 
pronounced in relation to financial information. In the case of a sales company 
doing a substantial volume of business, for example, preparation of a state sales 
tax return may take ten man-days or more. An audit may take a similar amount of 
preparation. Closing the books on an accounting period is itself an arduous task. 
The time requirements and challenges posed by month-end and year-end closings 
are all-too-familiar to virtually all in-house accountants. Despite these heroics, the 
inherent latency of the process diminishes the value of the results. A finalized June 
statement, for example, might be received at the end of July or the beginning of 
August, hampering the ability to react quickly to changing business conditions. A 
real-time financial statement is non-existent. 

For lack of readily-available, verifiable information in usable form, 
employee evaluation is often performed more on the basis of perception than 
objective reality. The appearance of performance then becomes at least as impor- 
tant as real performance. Employee performance and employee morale may suffer 
as a result. 
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Numerous "high-power" database application software packages exist in 
the marketplace, from such industry leaders as SAP, Peoplesoft, BAAN, and Ora- 
cle. The solutions of each of these vendors have strengths and weaknesses. SAP, 
for example, although strong in the area of fixed asset management and financial, 
does not provide flexible shipping and receiving functions. To automate these 
functions requires the use of separate software. Furthermore, Web integration is 
problematic. BAAN is strong in the areas of shipping/receiving, manufacture and 
assembly, but is limited in the areas of fixed asset management and material han- 
dling. In particular, BAAN, SAP, etc. are bound by conventional notions of real 
inventory — an item must physically be in stock before it can be ordered (as con- 
trasted with the concept of virtual inventory, explained more fully hereinafter). 
Peoplesoft offers strong human relations functions but is not strong in "back-end" 
functions. Software packages from Peoplesoft and BAAN are therefore often 
linked together to provided a more complete solution. Similarly, software from 
SAP may be linked to software from BAAN. Oracle offers discrete modules for 
almost all of the functions offered by the other software packages. The modules 
must be linked together in a laborious process, however, with substantial duplica- 
tion of data in all modules. None of these software packages have a Web-centric 
design, nor has any been used to successfully implement an automatic ene-to-end 
business process, even in large corporations having no lack of resources. 

Web-centric "e-business solutions" are offered by Pandesic (Intel and 
SAP), Actra (Netscape) and other (typically early-stage) companies. In the case of 
Pandesic, early promotional materials indicate a distinct consumer orientation as 
opposed to business-to-business. A conventional real inventory model is followed 
in which product must be warehoused and on-hand in order to allow the product to 
be ordered. Furthermore, Web operations are segregated from non-Web opera- 
tions, necessitating duplication. In the case of Actra, a portfolio of commerce soft- 
ware, including legacy application integration modules, are designed to "bridge 
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gaps between enterprises and applications/* enabling business-to-business transac- 
tions, buyer-side and seller-side procurement, consumer on-line Internet store- 
fronts, and commercial Internet publishing. This "gap-bridging" approach likewise 
entails substantial duplication. 

Dell and Cisco each sells computer and networking equipment directly to 
consumers over the Web using configuration and order software developed by out- 
side third parties. Business-to-business features, such as invoices, RMAs (particu- 
larly automatic "instant" RMAs) are lacking. The software does not provide an 
end-to-end Web-business solution. 

The need for more powerful business solutions is especially apparent in the 
area of supply-chain management. Currently, demand information is forecast- 
based and propagates slowly through a supply chain through manual processes. 
The result is frequent oversupply and undersupply. The power of the Web has not 
yet been brought to bear on the supply-chain management problem. 

A need therefore exists for software that enables end-to-end, business-to- 
business Web commerce and that automates to the greatest degree possible, in a 
unified and synergistic fashion, the various aspects of running a successful and 
profitable business. The present invention addresses this need. 

SUMMARY OF THE INVENTION 
The present invention, generally speaking, provides software that enables 
end-to-end, business-to-business Web commerce (Web business, or e-business) 
and that automates to the greatest degree possible, in a unified and synergistic 
fashion and using best proven business practices, the various aspects of running a 
successful and profitable business. Web business and business automation are both 
greatly facilitated using a computing model based on a single integrated database 
management system (DBMS) with intrinsic data synchronization that is either 
Web-enabled or provided with a Web front-end. The Web provides a window into 
a "seamless" end-to-end internal business process. The effect of such integration 
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on the business cycle is profound, allowing the sale of virtually anything in a trans- 
actional context (goods, services, insurance, subscriptions, etc.) to be drastically 
streamlined. In accordance with one aspect of the invention, business-to-business 
transaction processing using a database and a database management system is per- 
formed by receiving user demand information (or a user "wish list" or expression 
of interest interest in selected products) electronically; at least partially in response 
to receiving the user demand information electronically, automatically storing an 
order record in the database and maintaining the order record in the database 
throughout a life cycle of the order, and during the life cycle of the order, multiple 
users each accessing the order record and processing the order to accomplish a 
respective one of multiple business functions, and creating records related to the 
order. The life cycle of the order includes an expected period for at least one of 
reversal, service, and parts order, where reversal includes customer returns, cann- 
cellation and correction of improperly fulfilled or mistaken orders, including 
employee mistakes. The business software provides a Web-based, business-to- 
business electronic commerce framework that uses the Web as a medium for all 
parties involved in a transaction (customer, supplier, manufacturer, etc.) within 
multiple supply-chain tiers to receive up-to-the minute synchronized transaction 
information relating to any and all facets of the transaction. Information may be 
disseminated by push (Web broadcast) or pull methods, with a business user exer- 
cising information access control. 

In the case of a just-in-time product reseller, for example, the business soft- 
ware operates as follows. A comprehensive product list is updated electronically in 
real time or at regular intervals from various sources (e.g., by file download, over 
the Web, or from CD or floppy distributions or other media or even manual input). 
A graphical Web interface allows a user to obtain a quote based on the product list. 
The quote is assigned a quote number and saved in the DBMS and may be 
retrieved and viewed at a later date. Based on the quote, a user with appropriate 
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Web-verifiable authority may place an order on behalf of a company in accordance 
with a pre-existing Web-enforceable agreement with the company. An employee 
of the seller, using the same DBMS, purchases product to fill the order. When the 
product is received, information regarding receipt of the product is entered into the 
DBMS. Orders are assembled, shipped and billed, all using the same DBMS. Cus- 
tomers can retrieve previous quote records and view order and shipment status via 
the Web. Customer invoices are automatically generated upon shipment but may 
be modified if necessary by a supervisory user having the requisite authority. 
When a customer payment is received, details concerning the payment are entered 
into the DBMS. Vendor invoices and payments are also handled using the DBMS, 
and both customers and vendors can view payment status — invoice, credit (from 
returns), etc. — via the Web, allowing paper invoice copies to be dispensed with if 
desired. Returns are provided for and may be return of an entire piece of equip- 
ment or replacement of a warranted component part, and replacements may be 
electronically tracked. Parts tracking saves employee time that would otherwise be 
spent responding to customer inquiries, and also contributes to customer satisfac- 
tion through the convenient availability of timely information. 

Throughout the foregoing process, a period (e.g., off-peak or nightly) 
update process is performed in which consistency checks are performed and in 
which accounting information (including sales tax information) is collected, jour- 
nal entries made, and general-ledger entries posted. When records are edited, they 
are flagged to be checked during the period update so that adjusting entries may be 
made if necessary. At any time, the update process may be run and an accounting 
period closed. Real-time, audit-ready financial information accurate up to the day 
or up to the hour is available within minutes at the touch of a button without the 
need for a highly-trained accountant. A novice can facilitate the systematic perfor- 
mance of many functions typically performed by accountants, with periodic 
review and supervision by an accountant. 
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Because the DBMS is Web-enabled, given the appropriate privileges, a 
complete up-to-the-minute view of every aspect of a business is available from 
anywhere in the world. Telecommuting is greatly facilitated, with its attendant cost 
savings. Furthermore, factual evaluation of employee performance, whether of a 
telecommuting employee or an office-based employee, is greatly facilitated by sta- 
tistical analysis of accumulated historical performance data (tasks, projects, 
assignments, reports). 

Driven by the goals of enabling widespread telecommuting and global 
cyberspace trading, the single database business process software provides parallel 
synchronized data access to all users. Users have access to all information given 
the proper access authority. The system provides built-in assurance of prioritized 
dynamic workflow and best business practice (the optimum known way that a 
business process should flow) based on self-correcting business knowledge algo- 
rithms. The system draws upon a knowledge base to prevent mistakes anticipated 
by the software designer as well as mistakes that have occurred in the past and 
have been corrected for by adding to the knowledge base, which is continually 
accumulating. The dynamic workflow assures that whatever mistakes may occur 
are discovered at various stages. The system lists and prioritizes uncompleted 
work that needs to be followed up. All user activities are tracked, and users are 
held accountable. Every activity performed by users are tracked statistically. Prob- 
lem sources may therefore be identified. Precision training and factual perfor- 
mance review are made possible, significantly empowering users in their 
assignments. 

The software provides for business scalability (as opposed to mere data 
processing scalability), minimizing the growing pains experienced by rapidly 
growing companies. In growing companies, as the responsibility for a process 
becomes divided among more and more people, becoming more and more diffuse, 
communication between group members becomes more and more difficult and the 
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process becomes increasing difficult to manage. The present invention, with 
dynamic workflow, makes workflow and work quality substantially immune to 
changes in the number of employees and the experience level of employees. Work 
discipline and organization is enforced by, and teamwork and communication 
between users facilitated by, the database. The ease of use of the database system 
arising from dynamic workflow and the knowledge base incorporated within the 
system minimizes the need for extensive employee training and allows for flexible 
employee roles. Business scalability also entails dramatically increased productiv- 
ity through automated computer assistance, allowing business growth to greatly 
outstrip personnel growth. One example of business scalability is in the area of 
purchasing. Orders are grouped for purposes of purchasing such that the number of 
purchase orders to vendors does not increase as the number of orders received. 

Conceptually, the invention allows for the integration and time-scale com- 
pression of what have heretofore been largely independent, human-dependent 
business processes. Business processes have typically been organized into separate 
business domains, chiefly including a products domain (e.g., engineering, manu- 
facturing, purchasing, shipping, receiving, returns), a payments domain (e.g., 
accounts receivable, accounts payable), a financial performance domain (e.g, gen- 
eral ledger, financial statements, tax returns) and a personnel domain (e.g., 
employee evaluation). In accordance with one aspect of the invention, files for the 
automation of these various business domains are integrated as part of a single 
database schema within a single database management system run on one or multi- 
ple servers. There results a very tight integration of the foregoing activities and 
other derivatives of those activities such as product forecasting and cash-flow 
analysis. In particular, a universal financial report and trend report generator pro- 
vides for general single or multiple General Ledger (GL) account code analysis 
including sales, cash flow and material. 

Time-scale compression of the resulting integrated business automation 
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process is achieved in two ways. First, the single database management system is 
Web-enabled, providing access anytime, anywhere. Second, triggers within the 
single database management system propagate activity from one business domain 
to a succeeding business domain (e.g., from shipping in the products domain to 
accounts payable in the payments domain) without duplication of human efforts. 
Data can only be entered once and is not ordinarily allowed to be changed or re- 
entered. Data entry is guided by a built-in best-practice knowledge base. 

The integrated business automation process may be easily modularized if 
desired by restricting access to only files belonging to selected business domains. 
Hence, unlike conventional business automation suites that provide separate soft- 
ware modules that may be acquired separately and linked together (with sustantial 
data duplication), in the case of the present integrated business automation pro- 
cess, a customer receives everything but may only pay for be given access to a sub- 
set of files — e.g. AP/AR files. Later the customer may decide to pay for added 
capabilities. Such a change in capabilities may be readily administered remotely 
through the Web. In this manner, the customer is able to "pick and choose" the 
capabilities that the customer wants to use. 

An outside Web user may also pick and choose the capabilities that the 
user wants to use. For example, orders may be placed by phone or fax but tracked 
via the Web. Or a user may use the Web only to check the amount owed on open 
invoices. Others user may use the Web from start to finish, to order products, track 
orders, track payments, etc. 

Extensive measures are taken to ensure that the integrated business process 
is, to the greatest extent possible, error-free. Only a limited number of controlled 
entry points to the system are provided. At each entry point, entry validation is per- 
formed at the time of entry. Because the business process is integrated, validation 
may be more extensive and hence more effective than in typical systems. A peri- 
odic update process is also performed is which checks are made, including cross- 
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checks between records of files belonging to different business domains. The sys- 
tem is in effect a closed system where all entries must balance appropriately. The 
nightly update is able to catch and flag errors (or possible errors) that may have 
occurred despite entry validation, including hardware or system errors, software 
bugs, and human errors. As errors become apparent that have escaped detection by 
the system, the foregoing mechanisms may be readily revised to prevent future 
such occurrences. Programmed process intelligence therefore continually 
increases as errors are detected, flagged, and trouble-shooted so as to add to the 
wealth of the knowledge base and improve the process methodology. At the same 
time, dynamic workflow makes possible the re-navigation of existing workflow 
components. 

The integrated processes also automates returns and credits both on the 
customer side and the vendor side. Returns and credits may be necessitated by user 
errors that go undetected by the system, by overcharges for freight, or numerous 
other circumstances. Returns are only one important example of what is more gen- 
erally a reversal process, or catch-all, for mistakes during work-in-progress and for 
post-sale activity. Return requests, Return Merchandise Authorizations, credit 
memos and accounting adjustments may all be handled electronically, 

BRIEF DESCRIPTION OF THE DRAWING 
The present invention may be further understood from the following 
description in conjunction with the appended drawing. In the drawing: 

Figure 1 is a block diagram illustrating conceptually a conventional busi- 
ness process; 

Figure 2 is a block diagram illustrating conceptually an automated business 
process in accordance with the present invention; 

Figure 3 is. a generalized block diagram of a system for business-to-busi- 
ness Web commerce in accordance with an exemplary embodiment of the 
invention; 

Figure 4 is an illustration of a starting Web screen display; 
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Figure 5 is an illustration of a first product categories screen display; 

Figure 6 is an illustration of a further product categories screen display; 

Figure 7 is an illustration of still a further product categories screen dis- 
play; 

Figure 8 is an illustration of a screen display displaying printer cables; 

Figure 9 is an illustration of a shopping basket screen display; 

Figure 10 is an illustration of a screen display allowing the user to search 
for products by manufacturer; 

Figure 1 1 is an illustration of a multi-search screen display; 

Figure 12 is an illustration of a core products search screen display; 

Figure 13 is an illustration of a core products search results screen display; 

Figure 14 is an illustration of a Products Search /PID screen display; 

Figure 15 is an illustration of a PID search results screen display; 

Figure 16 is an illustration of a PID screen display; 

Figure 17 is an illustration of a Products Search/APL screen display; 

Figure 18 is an illustration of a Products Search/Previous Quotes screen 
display; 

Figure 19 is an illustration of a quotes search results screen display; 
Figure 20 is an illustration of a quote screen display; 
Figure 21 is an illustration of a PID maintenance screen display; 
Figure 22 is an illustration of an active PIDs screen display; 
Figure 23 is an illustration of an APL maintenance screen display; 
Figure 24 is a company APL maintenance screen display; 
Figure 25 is an illustration of a return request screen display; 
Figure 26 is an illustration of an RMA multi-search screen display; 
Figure 27 is an illustration of an RMA search results screen display; 
Figure 28 is an illustration of an RMA record screen display; 
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Figure 29 is an illustration of a tracking screen display; 

Figure 30 is an illustration of a sales order status screen display; 

Figure 3 1 is an illustration of a sales order search results screen display;; 

Figure 32 is an illustration of a Tracking — Return Product and Service Part 
Status screen display; 

Figure 33 is an RMA status search results screen display; 

Figure 34 is an illustration of a more detailed RMA status screen display; 

Figure 35 is an illustration of a Tracking — Product Purchase History screen 
display; 

Figure 36 is an illustration of a Tracking — Product Return History screen 
display; 

Figure 37 is an illustration of a return history search results screen display 
displaying search results; 

Figure 38 is an illustration of a Reports screen display; 

Figure 39 is an illustration of a Back Order Reports screen display; 

Figure 40 is an illustration of a Monthly Sales Reports screen display; 

Figure 41 is an illustration of a resulting search results screen display; 

Figure 42 is an illustration of a Packing Slips screen display; 

Figure 43 is an illustration of a resulting search results screen display; 

Figure 44 is an illustration of a packing slip screen display displaying a 
selected packing slip; 

Figure 45 is an illustration detailing the authority of various internal users 
with respect to security parameters in accordance with an exemplary 
embodiment; 

Figure 46 is a diagram of a typical lineage (authority) tree; 

Figure 47 is an illustration of a database customer screen display; 

Figure 48 is an illustration of a company price list screen display; 

Figure 49 is an illustration of one of a series of dialogs used to set Web 
authority for an employee of a customer; 

Figure 50 is an illustration of another of a series of dialogs used to set Web 
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authority for an employee of a customer; 

Figure 51 is an illustration of another of a series of dialogs used to set Web 
authority for an employee of a customer; 

Figure 52 is an illustration of another of a series of dialogs used to set Web 
authority for an employee of a customer; 

Figure 53 is an illustration of another of a series of dialogs used to set Web 
authority for an employee of a customer, 

Figure 54 is an illustration of a dialog used to confirm employee informa- 
tion at the conclusion of Web authorization; 

Figure 55 is an illustration of the corresponding screen display as shown in 
Figure 48, following Web authorization; 

Figure 56 is a block diagram of a conventional Web commerce computer 
architecture in which different functions are automated on different com- 
puting platforms, necessitating multiple interfaces; 

Figure 57 is a block diagram of the present Web commerce computer 
architecture in which all functions are automated on a single Web-enabled 
database, necessitating only a single interface; 

Figure 58 is an illustration of a partial database schema of one implementa- 
tion of the system of Figure 3, showing primary files and relationships; 

Figure 59 is a block diagram illustrating an automated business process in 
accordance with an exemplary embodiment of the invention; 

Figure 60 is an illustration of a Sales-MWS screen display; 

Figure 61 is an illustration of a Quote screen display; 

Figure 62 is an illustration of a Products screen display; 

Figure 63 is an illustration of a MWS screen display; 

Figure 64 is an illustration of a Purchasing view of a PRIS (Purchasing/ 
Shipping/Receiving/Installation) screen display; 

Figure 65 is an illustration of a Receiving view of the PRIS screen display; 

Figure 66 is an illustration of an Installation view of the PRIS screen dis- 
play; 

Figure 67 is an illustration of a Shipping view of the PRIS screen display; 
Figure 68 is an illustration of a PRIS Item Detail screen display; 
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Figure 69 is an illustration of an Expedite view of the PRIS screen display; 

Figure 70 is an illustration of an Ordered Not Received screen display; 

Figure 71 is an illustration of a Received Not Shipped screen display; 

Figure 72 is an illustration of an Expedite pop-up, allowing expedite status 
to be set from a MWS screen display; 

Figure 73 is an illustration of an RMA screen display; 

Figure 74 is an illustration of an Add RMA screen display used to initially 
create an RMA; 

Figure 75 is an illustration of an RMA add records screen display used to 
add information to an RMA; 

Figure 76 is an illustration of an RMA Automatic Request Completion file; 

Figure 77 is an illustration of an RMA Automatic Approval Limit file; 

Figure 78 is an illustration of a Customer RMA Automatic Approval file; 

Figure 79 is an illustration of a Vendor RMA Automatic Approval file; 

Figure 80 is an illustration of a Manufacturer RMA Automatic Approval 
file; 

Figure 81 is an illustration of a Web page used to automatically provide a 
customer with an RMA number in accordance with the foregoing auto- 
matic approval process; 

Figure 82 is an illustration of a Sales Tax Register screen display, including 
formulas used to calculate figures to be entered within each line of a sales 
tax return; 

Figure 83 is an illustration of a Customer Invoices screen display; 

Figure 84 is an illustration of the Customer Invoices screen display show- 
ing collections information within a pop-up window; 

Figure 85 is an illustration of the Customer Invoices screen display show- 
ing collections information by customer within a pop-up window; 

Figure 86 is an illustration of a Customer Payments screen display; 

Figure 87 is an illustration of an OverUnderPay screen display; 

Figure 88 is an illustration of an OverUnderPay details screen display; 

Figure 89 is an illustration of a Vendor Invoices screen display; 
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Figure 90 is an illustration of an AP Add Invoices screen display; 

Figure 91 is an illustration of a Vendor Invoice display; 

Figure 92 is an illustration of a Daily Vendor Verification screen display; 

Figure 93 is an illustration of a Vendor Payment Register screen display; 

Figure 94 is an illustration of an Add Invoices screen display having super- 
imposed thereon a dialog window used to enter the period for a freight bill; 

Figure 95 is an illustration of an Accounting Setup defaults screen display; 

Figure 96 is an illustration of a display screen used to add an account to a 
Chart of Accounts file; 

Figure 97 is an illustration of a Chart of Accounts screen display; 

Figure 98 is an illustration of a Chart of Accounts — Account Detail screen 
display; 

Figure 99 is an illustration of an Accounts Receivable Customer Setup 
screen display; 

Figure 100 is an illustration of an Accounts Receivable screen display; 

Figure 101 is an illustration of an Accounts Receivable — Account Detail 
screen display; 

Figure 102 is an illustration of an Accounts Payable Partner Setup screen 
display; 

Figure 103 is an illustration of an Accounts Payable screen display; 

Figure 104 is an illustration of an Accounts Payable — Account Detail 
screen display; 

Figure 105 is an illustration of an account distribution pop-up screen used 
to allocate an invoice amount between different accounts; 

Figure 106 is an illustration of a General Journal output screen display; 

Figure 107 is an illustration of General Journal input screen display; 

Figure 108 is an illustration of a screen display used for financial report 
definition; 

Figure 109 is an illustration of a resulting financial report; 

Figure 1 10 is an illustration of a screen display used for trend report defini- 
tion; 
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Figure 1 1 1 is an illustration of screen display including a dialog used to 
select trend frequency; 

Figure 1 12 is an illustration of screen display including a window in which 
trend report data are displayed; 

Figure 1 13 is an illustration of a trend report graph screen display; 

Figure 1 14 is a block diagram of a human resource infrastructure for a vir- 
tual organization performance evaluation model; 

Figure 1 1 5 is an illustration showing in greater detail portions of the human 
resource infrastructure of Figure 1 14; 

Figure 1 16 is an illustration of a file structure used to track all performance 
metrics of interest; 

Figure 1 17 is an illustration showing in greater detail the Factual Measure- 
ment Review process of Figure 1 15; 

Figure 1 18 is an illustration of a seris of selection menus used to select an 
employee for whom a factual employee evaluation report is to be dis- 
played; 

Figure 1 19 is an illustration of screen displays used to display factual per- 
formance analysis results in accordance with an exemplary embodiment of 
the invention; 

Figure 120 is an expanded view of the multiple period screen display of 
Figure 119; 

Figure 121 is an illustration of a dialog displayed as a result of qualification 
of user inputs during the course of adding invoices; 

Figure 122 is an illustration of a further dialog of a similar type as that of 
Figure 121; 

Figure 123 is an illustration of yet a further dialog of a similar type as that 
of Figure 121; 

Figure 124 is a partial illustration of a pop-up menu of options available 
during vendor invoice display; 

Figure 125 is a partial illustration of a pop-up menu of options available 
during vendor invoice display, showing options not shown in Figure 124; 

Figure 126 is an illustration of a pop-up menu of options available during 
customer invoice display; 

Figure 127 is an illustration of a pop-up menu of options available during 
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display of items sold; 

Figure 128 is an illustration of a pop-up menu of options available during 
display of sales records; 

Figure 129 is a block diagram illustrating a knowledge base, the expression 
of the knowledge base in screen displays of the present system, and a man- 
ner in which the knowledge base is increased; 

Figure 130 is an illustration of an RMA Reports screen display; 

Figure 13 1 is an illustration of an RMAs pending approval screen display; 

Figure 132 is an illustration of an open RMAs screen display; 

Figure 133 is an illustration of a Shipping Reports screen display; 

Figure 134 is an illustration of a summary shipping report screen display; 

Figure 135 is an illustration of a detailed shipping report screen display; 

Figure 136 is an illustration of a POD screen display; 

Figure 137 is an illustration of an Accounting Reports screen display; 

Figure 138 is an illustration of a date-range-limited accounting report 
screen display; 

Figure 139 is an illustration of an invoice screen display; 

Figure 140 is an illustration of a multiple invoice search screen display; 

Figure 141 is an illustration of a customer collections screen display, show- 
ing a Get Problems dialog; 

Figure 142 is an illustration of the customer collections screen display 
showing a Searches pick box; 

Figure 143 is an illustration of the customer collections screen display 
showing a Select Problem dialog; 

Figure 144 is an illustration of the customer collections screen display 
showing a Select Tickler dialog; 

Figure 145 is an illustration of a purchasing output screen display; 
Figure 146 is an illustration of an expediting output screen display; 
Figure 147 is an illustration of a receiving output screen display; 
Figure 148 is an illustration of an installation output screen display; 
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Figure 149 is an illustration of a shipping output screen display; 

Figure 1 50 is a flow diagram illustrating a percolation process for purchas- 
ing; 

Figure 151 is a flow diagram illustrating a percolation process for receiv- 
ing; 

Figure 152 is a flow diagram illustrating a percolation process for shipping; 

Figure 153 is a flow diagram illustrating a percolation process for installa- 
tion/assembly; 

Figure 154 is a flow diagram illustrating supply chain integration/manage- 
ment features of the present invention; 

Figure 1 55 is a diagram of a first electronic template for specifying a cus- 
tomized business relationship; 

Figure 156 is a diagram of a second electronic template for specifying a 
customized business relationship; 

Figure 157 is a block diagram of a client/server business automation sys- 
tem in which a common database supports both end-to-end business pro- 
cess automation and sales force automation; 

Figure 158 is a more detailed representation of sales force automation 
capabilities of the the system of Figure 157; 

Figure 159 is a detailed listing of RMA types and sub-types; 

Figure 160 is an illustration of a screen display showing customer-specific 
automatic RMA approval criteria; and 

Figure 161 is an illustration of a Sales Force Automation screen display. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
Architecture 

Referring now to Figure 2, the present automated business process may be 
imagined as a kind of information assembly line. A first system user, or "informa- 
tion worker," having for example a Sales assignment or activity focus, initiates an 
automated, end-to-end business process by entering information into a client/ 
server single relational database, which forms a common hub of the automated 
business process. The user's entry is qualified, or "quality checked," as repre- 
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sented by a checkvalve. Such qualification is "experiential," i.e., derived from 
actual business experience, and differs qualitatively from the type of data valida- 
tion typically performed in database systems. If the user's entry fails scrutiny by 
the system, it cannot be committed to the database. Similarly, the business process 
cannot continue to the next user. As a result in part of such experiential qualifica- 
tion, verifiable and usable management and enterprise information may be made 
readily available. 

In the case of conventional systems, by contrast, a team of software engi- 
neers write an application based on input from groups of users from different 
departments to produce a definitive, linear workflow. The users, however, cannot 
anticipate the need for various features prior to using the software. Furthermore, 
the conception of the programmers may often differ significantly from that of the 
users. The result often leaves much to be desired. In SAP, BAAN, and other data- 
base systems, exceptions to the workflow must all be programmed. Updates are 
delayed until the next version of the software, at which point the same cycle 
repeats. Meanwhile, users suffer. Furthermore, because different users have differ- 
ent concerns, little consideration is given to the up-stream and down-stream effects 
of different user's actions. There results a "disconnect" between the behavior of 
the system and day-to-day real-world needs. 

In the present system, navigation of the workflow is soley determined byt 
he access authority of the user. Workflow components are all pre-existing and pre- 
programmed. User inputs to the system, however, do undergo a qualification pro- 
cess. Qualification of user inputs has multiple facets. First, each user is accorded 
limited access privileges. An authority check is therefore performed to ensure that 
the user is authorized to make the entry being attempted. Second, the entry is 
checked in accordance with business rules that embody best practice as determined 
from an analysis of expected parameters and how various values of those parame- 
ters affect possible outcomes downstream. Thirdly, entries, even after then are 
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committed to the database, are subjected to intelligent consistency checks in order 
to detect discrepancies and provide feedback to allow for correction. If input qual- 
ification is successful, then succeeding events in the sequential business process 
are triggered. 

Each worker in turn builds upon the information base established by pre- 
ceding workers, and each workers entries are rigorously qualified. For example, 
following sales, process flow may continue to Sales Support, Accounting, Pur- 
chasing, Receiving, Assembly, and Shipping. 

During the process external influences occur. An external influence may be 
a communication from a customer or vendor, for example, to either convey infor- 
mation or to view information stored in the central database. An example of an 
external influence might be a vendor special rebate. Information may be conveyed 
by electronic means (e.g., Internet, intranet, EDI, satellite, remote terminal direct- 
dial), human-mediated telecommunications (e.g., email, phone, fax), or by physi- 
cal means (letter, visit, etc.). 

As compared with the conventional business process of Figure 1, the circu- 
lar automated business process of Figure 2 revolves around a single integrated 
database that accumulates information regarding every important activity of every 
user and defines a non-repetitive process. Furthermore, as compared to the essen- 
tially non-reversible process of Figure 1, the process of Figure 2 is reversible. As 
seen in Figure 2, following Shipping is a Return/RMA (Return Merchandise 
Authorization) activity, or, more generally, a reversal activity. This activity 
enables the forward process to be reversed, or backed out of step-by-step, as part 
of the overall automated business process. 

The cumulative nature of the database of Figure 2 and the sequential nature 
of the business process enables incisive factual analysis in the areas of employee/ 
vendor performance and customer satisfaction, promoting fairness and personal 
responsibility. Whereas a human supervisor may effectively supervise only a lim- 
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ited number of employees, the database-implemented business methodology of 
Figure 2 provides for each employee what may be regarded as a "virtual mentor:" 
the user is guided during use of the system to prevent common mistakes (in fact, 
all mistakes made collectively by the all of the user's predecessors functioning in 
the same assignment), and the user's performance is continuously tracked and 
made accessible. Strengths and weaknesses in the employees performance may 
recommend certain changes in assignments — which changes may be made rela- 
tively easily by the employee because of the intuitiveness and intelligence of the 
system. An important aspect of virtual mentoring is an "open-book" information 
access policy: users, although they may limited access to input information, typi- 
cally have few if any limits on access to information. The virtual mentoring pro- 
cess, described in greater detail hereinafter, promises to make the virtual office and 
telecommuting, with all its attendant advantages, a practical reality for a much 
wider segment of the workforce. 

Referring now to Figure 3, a block diagram is shown of a computing envi- 
ronment in which the present invention may be used. A Web-enabled, client/server 
relational database management system (DBMS) is provided storing a database 
including files belonging to different business domains, e.g. a products domain, a 
payments domain, a financial performance domain and a personnel domain. (The 
term "product" is used generically herein to refer to items sold and may be tangible 
goods, financial products, subscriptions — anything that may be bought and sold in 
a discrete transaction.) Also provided are code modules pertaining to each of the 
different domains. Customers and vendors may obtain access to the database 
through the Internet or the like. The physical location of the database therefore 
becomes irrelevant — the database can be everywhere in the world, either through 
wired communications or wireless communications. A firewall (or other security 
scheme, such as encryption, implemented in either hardware or software) may be 
provided between the Internet and the Web interface of the DBMS. Internal clients 
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may be connected to the DBMS through a local area network (LAN) or through an 
intranet, using the Web interface. 

Web User Interface 

The Web interface to the database, particularly as seen by the customer, 
will presently be described in greater detail. 

Referring now to Figure 4, within a principal navigation path a Web user is 
presented with buttons representing various options. In an exemplary embodiment, 
these options relate to, respectively, products, returns/repair, tracking, reports, 
accounting and log off. Two further options are also presented, PID maintenance 
and APL maintenance, the functions of which will be made clear hereafter. 

In the example of Figure 4, the Products button is assumed to have been 
selected, resulting in the display of various search options. In the illustrated 
embodiment, Options 1-4 draw from an electronic products catalog directly. A 
product listing may be obtained by product category, all manufacturers (Option 1) 
or a single manufacturer (Option 2), or by manufacturer, description or part num- 
ber (Options 3 and 4). Options 5-8 do not draw from the electronics products cata- 
log directly but instead allow ordering to be performed without interacting directly 
with an electronic products catalog as described hereafter. 

Selecting Option 1 causes a screen such as that of Figure 5 to be displayed, 
in which various product categories are displayed next to corresponding buttons. 
When the "Accessories & Supplies" button is selected, a screen such as that of Fig- 
ure 6 is displayed, in which various sub-categories of products are displayed next 
to corresponding buttons. This division and sub-division may have any number of 
levels. In the illustrated embodiment, selection of the "Cables & Connectors" but- 
ton causes a screen such as that of Figure 7 to be displayed, showing still a further 
level of sub-division. When the "Printer" button is selected, a screen such as that 
of Figure 8 is displayed, showing printer cables from the electronic product cata- 
log. The user may check items of interest and click on "Show Selected Items," 
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whereupon only the checked items are displayed. The user may search within the 
selection, reset (causing all of the items to again be displayed) or initiate a new 
search by clicking on corresponding buttons at the bottom of the page. For exam- 
ple, if the user checks the first item and clicks "Show Selected Items;' a "shopping 
basket" screen such as that of Figure 9 is displayed. The user may return to the pre- 
vious products list, search for more items, create a quote with the displayed items 
by entering a quantity for each item, or empty the shopping basket. 

Selecting Option 2 from the product search page (Figure 4) causes a screen 
such as that of Figure 10 to be displayed. The user inputs a manufacturer's name, 
or clicks on a letter of the alphabet to choose from a list of manufacturers whose 
names begin with that letter. 

Selecting Option 3 from the product search page (Figure 4) causes a screen 
such as that of Figure 1 1 to be displayed. The user inputs one or more of the fol- 
lowing items of information: manufacturer, item description and manufacturer part 
number. Multiple part numbers may be entered and search simultaneously by 
clicking the "Search multiple products" button. 

Selecting Option 4 from the product search page (Figure 4) causes a screen 
substantially similar to that of Figure 10 to be displayed. 

Selecting Option 5 from the product search page (Figure 4) causes a screen 
such as that of Figure 12 to be displayed. This screen is similar to that of Figure 1 1 . 
However, instead of merely searching the electronic catalog, the search identifies 
products that meet the criteria specified and that have previously been purchased 
on the user's account ("core products"). The search may be date limited. Alterna- 
tively, the user may choose to display all core products by clicking the correspond- 
ing button. Figure 13, for example, shows a list of core products resulting from the 
search criterion "Compaq." 

Selecting Option 6 from the product search page (Figure 4) causes a screen 
such as that of Figure 14 to be displayed. Rather than purchase products item by 
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item, the present system allows the user to store groups of items that work together 
as pre-configured products, each identified by a user-assigned Product group ID 
(PID). The user may search for a specific PID or multiple specific PIDs, or the user 
may show all PIDs. An example of a screen display that results when the user 
clicks "Show all PIDs" is shown in Figure 15. PIDs may be regarded as a "favorite 
quotes" list that may be repeated reused by the user. An example of a PID is shown ' 
in Figure 16. 

Selecting Option 7 from the product search page (Figure 4) causes a screen 
such as that of Figure 17 to be displayed. In addition to PIDs, the present system 
allows Approved Product Lists (APLs) to be stored, including both a company 
APL and a personal APL. The user may search an APL or show an APL in its 
entirety. 

Selecting Option 8 from the product search page (Figure 4) causes a screen 
such as that of Figure 18 to be displayed. This option allows previous quotes to be 
found and displayed. The user may specify a particular quote by quote number or 
may display the quotes for the current day or the current week. The quote or quotes 
that are found are displayed within a screen display such as that of Figure 19. 
Selecting a quote and clicking "Show selected Quote" causes a screen such as that 
of Figure 20 to be displayed. Various actions may be taken with respect to the 
quote including: add/change/remove products; arrange the order of quote items; 
save the quote for future reference; place an order based on the quote; and dupli- 
cate the quote into a new quote. The user may also return to the last search results 
of the Products List. 

PIDs and APLs may be maintained on-line by the user. Clicking on the PID 
Maintenance button within the screen of Figure 4 causes a screen such as that of 
Figure 21 to be displayed. The user may create a new PID or review existing PIDs. 
For example, clicking on the "Show PIDs currently Active" causes a screen such 
as that of Figure 22 to be displayed. The user may click on a PID number to view 



WO 99/33016 



27 



PCT/US98/27496 



the PID in detail. 

Clicking on the APL Maintenance button within the screen of Figure 4 
causes a screen such as that of Figure 23 to be displayed. The user then chooses 
between company APL and personal APL. Clicking on "Company APL," for 
example, causes a screen such as that of Figure 24 to be displayed. The user may 
add or delete an item to or from the APL by manufacturer part number or take any 
of various action with respect to the APL, including: search for products to add to 
the APL; delete items from the APL; end APL maintenance; and sort APL items 
by part number, manufacturer, price or description. 

Clicking on the Returns/Repair button within the screen of Figure 4 causes 
a screen such as that of Figure 25 to be displayed. This screen allows a user to 
identify, in any of various ways, a product to be returned or repaired. For example, 
the product may be identified specifically by serial number, asset tag number, or 
the order to which the product belongs can be identified by customer purchase 
order number, customer invoice number, customer Purchase Requisition Number 
(PRN), or customer Request For Quote (RFQ) number. Clicking on the "More 
Search Options" button causes a screen such as that of Figure 26 to be displayed. 
From this screen, the user can search for a product to be returned by manufacturer 
name, part number and/or purchase date. The user may also look up Return Mer- 
chandise Authorization (RMA) records by date. Figure 27, for example, shows 
RMAs created between 6/2/98 and 7/1/98. Clicking on the RMA number causes 
the corresponding RMA record to be displayed as shown, for example, in Figure 
28. 

Clicking on the Tracking button within the screen of Figure 4 causes a 
screen such as that of Figure 29 to be displayed. The user selects the type of track- 
ing information desired: sale order status, return product and service part status, 
product purchase history, or return and service history. If other status information 
is desired, the user may describe the desired information and submit a an email 
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request. In essence, the present system allows remote users, including customers, 
vendors, manufacturers, etc., to view relevant status information pertaining to 
most or all of the product life cycle stages: purchasing, receiving, shipping, instal- 
lation/assembly, billing, return/service, etc. 

Clicking on "Sales Order Status" (Figure 29) causes a screen such as that 
of Figure 30 to be displayed. A sales order may be identified by customer purchase 
order number, customer invoice number, customer Purchase Requisition Number 
(PRN), or customer Request For Quote (RFQ) number or by identifying an item 
belonging to the order, by serial number or asset tag number. If the user does not 
have any of this information, the user may search for sales orders by manufacturer, 
part number, and/or date range. Figure 3 1, for example, shows the result of search- 
ing for sales orders by manufacturer (Compaq). 

Clicking on "Return Product & Service Part Status" (Figure 29) causes a 
screen such as that of Figure 32 to be displayed. RMAs may be identified by RMA 
number, temporary case number, quote number, or by any of the various pieces of 
information referred to in previously (PO number, etc.). Figure 33, for example, 
shows RMAs identified by PO number. The user checks one or more RMAs of 
interest and then selects an action to take, e.g., "Get Freight Carrier & Tracking #" 
or "Ship to Address." Selecting "Get Freight Carrier & Tracking #" causes a 
screen such as that of Figure 34 to be displayed. 

By clicking on "Product Purchase History" (Figure 29), the user may dis- 
play by date range items previously purchased. Figure 35, for example, displays 
items purchased from Oct. 4, 1998 to Oct. 5, 1998. Similarly, clicking on "Product 
Return History" causes a screen such as that of Figure 36 to be displayed. Figure 
37 displays items returned from Apr. 1, 1998 to May 1, 1998. 

Clicking on the Reports button within the screen of Figure 4 causes a 
screen such as that of Figure 38 to be displayed. The reports may include such 
reports as the following: Back Order Reports, Monthly Sales Reports, Packing 
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Slips, RMA Reports, Shipping Reports, etc. 

Clicking on "Back Order Reports" (Figure 38) causes a screen such as that 
of Figure 39 to be displayed. Some units of an item may have been shipped but not 
all. If so, the 1st Ship and Last Ship fields indicate when the first unit of that item 
was shipped and when the last unit was shipped. 

Clicking on "Monthly Sales Reports" (Figure 38) causes a screen such as 
that of Figure 40 to be displayed. The user selects a date range or a month and 
clicks "Take Action." A display such as that of Figure 41 results, listing each item 
sold on the user's account during the period, including total quantity, total cost, 
average unit cost and number of times ordered. Also displayed is the status of each 
purchase order for the period, the grand total of all purchases for the period, and 
the number of orders. 

Clicking on "Packing Slips" (Figure 38) causes a screen such as that of 
Figure 42 to be displayed. Packing slips may be searched by providing a piece of 
identifying information in similar manner as described previously or may be iden- 
tified by month. Figure 43, for example, shows packing slips for the month of Oct., 
1998. Clicking on the packing slip number causes the packing slip to be displayed, 
as shown in Figure 44. 

Clicking on "RMA Reports" (Figure 38) causes a screen such as that of 
Figure 130 to be displayed. The user is presented with various options, for exam- 
ple, show approved RMAs, show pending RMAs, show all open RMAs, etc. 
Clicking on Option 1 causes a screen such as that of Figure 13 1 to be displayed. By 
clicking on an RMA number, details of the RMA may be displayed. Clicking on 
Option 2 causes a similar screen to be displayed, showing only RMAs that have 
been approved. Clicking on Option 3 causes a screen such that of Figure 132 to be 
displayed, showing all open RMAs. 

Clicking on "Shipping Reports" (Figure 38) causes a screen such as that of 
Figure 133 to be displayed. The user is prompted to specify a date range for gener- 
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ating a shipping report. Clicking on "Submit" causes a screen such as that of Fig- 
ure 134 to be displayed, summarizing the number of shipping records found. 
Clicking on "Show All Details" causes a screen such as that of Figure 135 to be 
displayed. Items shipped during the specified period are displayed by PO number. 
Clicking on "POD" for a particular item causes Proof of Delivery information for 
that item to be displayed as shown, for example, in Figure 1 36. In addition, the 
user may request email status updates for an order by clicking the corresponding 
link. As the order status changes, the user will then be automatically informed by 
email. 

Clicking on the Accounting button within the screen of Figure 4 causes a 
screen such as that of Figure 137 to be displayed. The user can retrieve particular 
invoices and credit memos by supplying any of various pieces of identifying infor- 
mation, or can retrieve invoices and credit memos by date range. Retrieving by 
date range causes a screen such as that of Figure 138 to be displayed. By clicking 
on the appropriate button, the user can display a selected invoice, purchase order, 
or packing slip. Clicking an invoice button, for example, causes a screen such as 
that of Figure 139 to be displayed. 

The user can also enter a list of invoice numbers to be retrieved. More par- 
ticularly, selecting Option 8 within the screen of Figure 137 causes a screen such 
as that of Figure 140 to be displayed. The user can then enter as many invoice 
numbers as desired. 

A user may create one or more quotes but not act on the quotes for a con- 
siderable period of time. The quotes serve as an expression of interest on the part 
of the user. As time passes, however, the liklihood of a quote becoming an order 
decreases. In accordance with one aspect of the invention, such quotes are auto- 
matically identified, and communication with the users is undertaken so as to 
increase the liklihood of quotes being converted to orders. The communication 
may be Web-based and may, for example, take the form a promotional offer. 
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As may be appreciated from the foregoing description, the system provides 
for "information-rich" invoice payment status tracking and display. The simple 
knowledge that an invoice is open (has not been paid) is of little value. The more 
pressing question is why a customer invoice should be paid (e.g, has a return ques- 
tion been resolved?) or why vendor invoice has not been paid (e.g., was sales tax 
incorrectly charged?). The present system is designed to track such invoice pay- 
ment status information. Because the database is Web-enabled, the same informa- 
tion may be readily displayed to customers and vendors, avoiding the need for 
telephone calls, "telephone tag," etc. 

The present Web user interface is designed to accomodate a wide range of 
users, ranging from unsophisticated to sophisticated. To accomodate the unsophis- 
ticated user, any of various bits or pieces of information may be used to retrieve a 
record, for example the approximate purchase date. To accomodate the sophisti- 
cated user, multiple identifiers may be entered at a time in order to retrieve multi- 
ple records at a time, e.g., multiple part numbers, invoice numbers, RMA numbers 
(Return Merchandise Authorization numbers, described more fully hereafter), etc. 
This feature allows a user to quickly access a collection of desired information 
quickly with a single click. This feature is especially powerful in connection with 
RMAs. Instead of selecting items one at a time in order to create return requests, a 
user may enter several or many identifiers of a particular type (e.g., P.O. numbers, 
invoice numbers, asset tag numbers, etc.) and create a corresponding number of 
return requests. 

Preferably, this same multiple-entry feature is provided in an internal client 
user interface in addition to the Web user interface. 

Web Security 

Doing business electronically poses various security risks. In the case of 
consumer-oriented Web commerce, much attention has been focused on secure 
transmission of credit card numbers and various security mechanism have been 
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made available. In the case of business-to-business Web commerce of the type 
described, payment is usually not by credit card except for very small transactions. 
Instead, security risks involve potential abuse of the system by external parties or 
even internal parties. The present invention implements various security mecha- 
nisms to eliminate or minimize the potential for such abuse. Fundamentally, the 
security mechanisms are based on concepts of authority and lineage. A simple 
example is that the ship-to address for an order cannot be changed on-line. This 
prevents someone from ordering products and having them sent to their home or 
elsewhere. 

Lineage relates authority to organizational hierarchy. The organizational 
hierarchy of Web users for a particular customer may be represented in tree fash- 
ion. A user at the leaf level may be given authority to get quotes but not to place 
orders. A user at a next-higher level may be given authority to view the quotes of 
users within a limited sub-tree and may be given limited authority to place orders. 
A user at the root of the tree may be given unlimited authority, from the standpoint 
of the customer, to view quotes of any user and place orders in any amount. 

Referring generally to Figure 46, in the case of a typical company, various 
end users will be given different levels of authority, e.g., to create quotes but not 
purchase, to track orders, to perform returns, to view order information via the 
Web, or, in the most limited case, to have no access to Web purchasing informa- 
tion. To initiate the purchase process, an end user makes a quote request to his or 
her supervisor, who must approve the request. The request may require multiple 
further approvals, for example of an MIS department, an accounting department, a 
material management department, etc. In a typical scenario, the material manage- 
ment department will forward an approved request to a purchasing department. 
Authorized persons within the purchasing department may then send an order via 
the Web. In every instance, when Web access is attempted (and in fact every time 
a TCP packet is received), a user's authority is checked and that user's interaction 
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via the Web is limited to the scope of that authority. 

External Web authority information is stored for each customer in a cus- 
tomer file. An example of a customer record is shown in Figure 47. From the cus- 
tomer file, a company price list record such as that of Figure 48 may be displayed. 
For each customer, a price basis may be agreed upon for items that the customer 
buys regularly. External Web authority information is stored as part of the cus- 
tomer price list. 

The manner in which a external Web user's authority is specified is illus- 
trated in a series of figures beginning with Figure 49. First, the user's name is 
entered, first name (Figure 49) then last name (Figure 50). An employee number 
may then be entered (Figure 51), absent which an arbitrary employee number is 
generated automatically. A dialog then asks whether the user is authorized to make 
Web purchases (Figure 52). If the user is authorized to make Web purchases, then 
a further dialog calls for a purchase limit, if any, to be specified (Figure 53). A 
confirmation dialog is then displayed (Figure 54). The customer price list record 
following addition of the Web user with specified authority is shown in Figure 55. 

The specific limits placed on a user's purchase authority may vary. Other 
examples of limits that may be desired by some companies are a limit on the num- 
ber of purchase orders per day, a limit on the total amount of purchase orders per 
day, a time-of-day limitation as to when orders may be placed, etc. Various other 
security parameters may be added. Such limits may be set and changed remotely 
via the Web and given immediate effect within the system. 

Limits are also placed on internal users access to security parameters so as 
to provide customer assurance that there exists no potential for internal abuse of 
the system (e.g, authorizing a crony to make illicit purchases on a customer 
account). A user may have authority to use (view) but not approve changes to cer- 
tain security parameters, and may have authority to use and approve changes to 
other security parameters. In an exemplary embodiment, the authority of various 
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users is set as illustrated in Figure 45. 

Catalog Management 

In the case of a company based on the conventional model of real inven- 
tory, Web catalog management is relatively straightforward. In the case of a com- 
pany based on the model of virtual inventory, "the world is your warehouse " 
Intelligent catalog management is therefore of vital importance. Intelligent catalog 
management, in an exemplary embodiment, is based on a concept of "baseline." A 
baseline is a collection of products that functions as a standard of comparison. In 
an exemplary embodiment, there is both a vendor baseline and a customer base- 
line. Using the baseline concept, a product list without duplicates may be dis- 
played. Furthermore, there may be displayed to the customer only products that 
there is some reasonable likelihood of the customer buying. 

On the vendor side, one vendor is selected to serve as the baseline vendor. 
The baseline vendor will typically be a vendor found to have the most comprehen- 
sive inventory, the most useful categorization scheme, etc., and may be varied as 
often as desired. To create an update baseline, product listings of vendors are com- 
pared with the current baseline. If a product is already part of the baseline, as 
determined by manufacturer part number, then the product is grouped under the 
same baseline listing. For example, the same computer may be available through 
multiple different vendors. Rather than creating multiple product listings for the 
same product, these multiple product listing are consolidated under a single base- 
line product listing. If a product is not in the baseline, it may be added to a "supple- 
mental baseline." If the baseline vendor does not carry a particular product but one 
or more alternate vendors carry the product, then the product will be listed in the 
supplemental baseline, again without duplicates. 

After an updated baseline has been compiled, it is compared with the previ- 
ous baseline. A product listing may be found: 1) in the old baseline only; 2) in the 
new baseline only; or 3) in both. Product listings in categories 1 and 2 are flagged 
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as discontinued products and new products, respectively. 

During the foregoing process, product cost and customer pricing informa- 
tion is updated. Also updated are URLs to vendor and manufacturer Web sites. 
These URLs may be used to refer Web users to these sites for product information. 
Product list updating may occur continuously or at regular intervals using "pull" 
technology, "push" technology, some combination of the two, or some other infor- 
mation retrieval technology or combination of technologies. 

On the customer side, a customer baseline is formed by combining: 1) cus- 
tomer APLs (Approved Product Lists) for all customers or some subset of custom- 
ers; and 2) historical purchase information, taking into account such factors as 
purchase date, volume, etc. There results a non-duplicative list of products custom- 
ers have bought or are presently approved to buy. Products in the vendor baseline 
may be flagged as belonging or not belonging to the customer baseline. 

As a result of the baseline concept and the power of the DBMS, great flex- 
ibility is provided in the manner in which products may be displayed. A user may 
search the product file and request to see new products, discontinued products, 
vendor baseline products, without duplicates, vendor baseline products expanded 
to show duplicates, customer baseline products, customer-specific APL products, 
etc. In this manner, the seeming chaos that would otherwise result from the "infin- 
itude" of products embraced by the notion of virtual inventory is tamed and made 
manageable. 

Much of the difficulty of successfully implementing a cohesive business- 
to-business Web commerce solution has resulted from different aspects of a com- 
pany's business being automated on different computing platforms. As illustrated 
in Figure 56, for example, a product catalog may be implemented on one platform, 
shipping implemented on another platform, accounting implemented on still 
another platform, etc. To interface all of these different functions to the Web 
requires multiple interfaces. 
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By using a single Web-enabled database and providing for all necessary 
functions within a single database schema, the present Web commerce solution 
avoids the daunting complexity characteristic of the prior art. Referring to Figure 
57, a single universal interface may be used to place the entire contents of the data- 
base, or as much of those contents as desired, on the Web. 

Database Schema 

An important feature of the present system is that a single database, 
described by a single database schema, is used to automate an overall business pro- 
cess, end-to-end. To do so, the schema must, understandably, be quite complex. A 
general outline of the schema is shown in Figure 58. The complete schema, or 
structure diagram, is set forth as Appendix A. 

Referring to Figure 58, the manner in which various automation processes 
relate on an inter-domain basis may be appreciated. The products domain is repre- 
sented in approximately the upper third of Figure 58 and includes sales functions 
(5801) and shipping/receiving functions (5803). Purchasing and installation func- 
tions, now shown in Figure 58, are shown in the microfiche appendix. The pay- 
ments domain is represented in approximately the middle third of Figure 58 and 
includes AP functions (5805), AR functions (5807) and return functions (5809). 
The financial performance domain is represented in approximately the lower third 
of Figure 58 and has financial information automatically posted to it from the pay- 
ments domain, as described more fully hereinafter. The personnel domain is not 
shown in Figure 58 but draws upon information from the other domains in a man- 
ner described more fully hereinafter. 

In an exemplary embodiment, the relational database management system 
provides both a "Quick Switch" option whereby any base table may be viewed or a 
"Related Switch" option (described in greater detail hereinafter) whereby a base 
table may be selected from which is then displayed a row related to a selected row 
in a current table. Various user options may be provided programmatically. Table 



WO 99/33016 



37 



PCT/US98/27496 



1 is a list of most of the base tables and corresponding options in an exemplary 
embodiment of the invention. 

Table 1 



Base Table 


(Options) 


Addresses 




Allocatedlndex 




AP_Registers 




AR_Registers 




Chart of Accnts 




Checking_Acts 




Ch Statements 




Claims 




Commission Reg 


Quick invoice lookup 
Quick credit lookup 

Get register 

Get not approved 

Get approved but not paid 

Approve 
Disapprove 

Change payment date 

Pay 
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Table 1 



Base Table 


(Options) 


Commissions 


Quick lookup by period 




Quick transaction lookup 




Quick PO lookup 




Quick MWS lookup 




Quick invoice lookup 




Quick credit memo lookup 




Get not approved 




Approve 




Get approved 




Schedule payment 




Notes 




HnlH 
nuiu 




Get hold 




Reset back 1 




Check commissions 




Recalculate commissions 




Change commission Email 


Contacts File 




CustCredMemos 


Quick memo lookup 




Credits not taken 




Credits taken 




Credits on hold 




Internal credits not taken 




Internal credits taken 




Hold credit memo 




Internal notes 




Customer notes 




Internal status change 
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Table 1 



Base Table 


(Options) 


Customers 


Add employee purchase record 




Approve customer 




Find employee 




List employees 


CustPayments 


Get not approved 




Get not posted 




Approve 

rr 




Post 


Custjnvoices 


Quick invoice lookup 




Cust invoice summary 




Print selection 




Comm report 




Get AR report selection 




Get not issued 




Get not oaid 




Get no charge 




Get Dre-naid 




i^iosc — no cnarge 




Split invoice 




Join 2 invoices 




Issue invoices 




Check for not issued invoices 


Defaults 




DropShipments 




FAX Templates 




Item Details 
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Table 1 



Base Table 


(Options) 


Items Sold 


Quick MWS# lookup 
Add MWS to fast order 

Open order reports 
Expedite/availability 

Customer notes 
CSR notes 

Status (restricted) 

Expand to all items sold 
Remove shipped 
Check selection again 
Update MWSs 

Clear updates 

Tech expedite 
Clear tech expedite 

Get in house not rcvd 
Receive in house 

Get installation not rcvd 
Receive installation 


MWSLog 




0 verUn d erP av 


Get not reconciled 
Get not cleared 
Get open 
Close 


Packing Slips 




Partners 


Find by expense account 
Vendor priority maintenance 


Personnel 




PED ItemsSold 




PIDs 




Products 
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Table 1 



Base Table 


(Options) 


Purchase Stats 




Purchasing 




Quote Detail 




Rcvd Boxes 




Receiving 


Receive 
Installation 
Update MWSs 

Double, wrong, defective, or no MWS 
Fill allocation 
Freight check 

Recover receiving register 


Report 




RMA 


Quick RMA lookup 
Quick case lookup 
Quick PO/PED/PRN/RFQ 
Get Web RMAs 

Update RMAs 

Expected cred summary 

Edit fax cover sheet notes 
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Table 1 



Base Table 


(Options) 


Sales Records 


dii'tnlr AAXXJQ.il. tnrklnirt 
I^UICK lYl W Off lOOKUp 




Quick quote# lookup 




Quick PO/RFQ/PID/PRN LU/conf 




PurchChecks 




Update MWSs 




Expedite/availability/purch 




Urgent 




Not Urgent 




Daily PO confirmation 




Get quotes 




Print quote confirmation 




Quotes requiring REVIEW 




Cancel REVIEW 




Get purchasing records 




Print purchase summary 




Clear updates 




Lock 




Unlock 




Get unlocked 




Change TPO to real PO 




Get temporary POs 




Get Web quotes 


Sales_Reps 




Sales_Support 




SalesJTaxes 


Recalc selection 




Add sales tax 
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Table 1 



Base Table 


(Options) 


Shipping 


Quick lookup by period 




Quick lookup by pickup number 




_ Following works in selection 








Get not reconciled closed 




Get reconciled open 




vJCL ICLrwXlCllCU LlUaCU 




Installation 




Update MWSs 




Freight check 




Reconcile freight 




Recover register 




Merge registers 


TaxRegister 


Due dates 




Update user selection 




Print user selection 




Sets window 


Tax_Tables 
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Table 1 



Base Table 


(Options) 


Ven Pmnt Regs 


Quick invoice lookup 




Quick credit lookup 




Get register 




Get not approved 




CrPt annrovpH hi it not nnirl 




Approve 




Disaoorove 




Change payment date 




Pay 




Get regs with credit balances 




Vendors with credit balances 




Close register 




Open register 


VenCollection 


Quick memo lookup 




Quick invoice lookup 




Ouick navment rpcrictpr lnnlciin 




Get not used 




Get excess/not distributed 




Get distributions 




Get exnected memos 




Reconcile expected memo 




Get not pre-approved 




Pre-approve 




Get pre-approved 








Get approved 




Schedule 




Reset status back 1 




Cancel credit memo 


VenMultiCred 
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Table 1 



Base Table 


(Options) 


VenRecExpCred 
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Table 1 



Base Table 


(Options) 


Ven_Invoices 


Quick invoice lookup 




Quick voucher lookup 




Quick check lookup 




Search selection by date 




Verify selection 




Daily verification 




Get all not paid 




Get not reconciled 




Get reconciled 




Reconcile with credit 




Pre-approve 




Get ore-annmved 




Remove ore-annroved 




APPROVE 




Get approved 




Schedule payments 




Schedule pre-paid payments 




Close selection 




HOLD selection 




Get hold 




Reset status back 1 




Edit terms/payment/vouchers 




Integrity check 




Temporary notes 




Update invoice 




Mark ready for review 




Get ready to review 




Mark reviewed 




Get reviewed 
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Various screen displays showing the options pop-up menu for that screen 
display are shown in Figure 124 through Figure 128. 

Business Process — Overview 

An overview of the present automated business process is shown in Figure 

59. In an illustrated embodiment, the automated business process has nine entry 
points, designated E1-E9, at which users enter information into the system. Inter- 
action with the system is carefully controlled and user inputs carefully qualified to 
ensure, to the greatest degree possible, error-free operation. 

The business process is customer-driven. The first entry point El in the 
business process is Sales/RMAs. In response to a customer request, a user having 
responsibility for El enters information about the customer request into the data- 
base. If the request regards sales, the information is checked and converted to a 
Master Worksheet (MWS). At an entry point E2, the responsible user groups 
MWSs for purchasing and places orders. Information is assembled for later use in 
receiving (E3), installation (E4), and shipping (E5). Respective users at these entry 
points make entries into the database which as confirmed against the assembled 
Purchasing/Shipping/Receiving/Installation (PRIS) information to verify correct- 
ness. 

Unlike prior art systems, the present system provides the option of carrying 
inventory or operating under the concept of virtual inventory. In accordance with 
the concept of virtual inventory, all of the goods available for purchase in all of the 
warehouses throughout the world are regarded as available inventory. Because the 
Web allows business to take place at light speed, the difference between physical 
inventory and no physical inventory can be merely the click of a button on a com- 
puter screen. As goods are received and shipped, these events are tracked by a vir- 
tual inventory process in which all items are presold. In one aspect of the 
invention, virtual inventory is defined as each vendor order item being related to at 
least one item sold record created in response to receiving user demand informa- 
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tion directly from a user; i.e., the system is "demand driven." 

Virtual inventory may be more fully understood in relation to the data pro- 
cessing concept of pipelining. Some delay occurs as the data pipeline is initially 
filled. Thereafter, results are produced at every cycle. The initial delay is the time 
required to perform a data operation on the data inputs. Similarly in the case of 
goods. An initial inventory of goods may be required to satisfy demand during a ' 
time period from when a demand is received until that demand can be filled — i.e., 
the manufacturing cycle. Thereafter, supply and demand should be exactly bal- 
anced. As demand increases and decreases, the rate of manufacture is varied 
accordingly such that supply and demand remain exactly balanced. In the case of a 
reseller, the manufacturing cycle is zero. The requirements for real inventory are 
therefore zero, enabling pure virtual inventory. In other businesses with non-zero 
manufacturing cycles (from days to weeks, months or years), the foregoing con- 
cept of virtual inventory may still be applied such that, in the "steady-state" condi- 
tion, supply and demand remain exactly balanced. 

Where physical inventory is required or desirable, it may be treated simply 
as an internal demand as opposed to a customer demand. In both cases, the demand 
is represented by an MWS. In the case of internal demand, however, the customer 
is the business itself 

Referring still to Figure 59, entry points E6 and E7 relates to customer and 
vendor payments, respectively. Assembled information is input to A/P and A/R 
modules. Customer payments are received and entered in conjunction with the A/P 
module. Vendor payments are made in conjunction with the A/R module. 

A general ledger (GL) module tracks transactions and their financial impli- 
cations in real time. It therefore receives information from the A/P, A/R and virtual 
inventory modules as well and entry points E6 and E7. Bank statement information 
is also input to the general ledger module at entry point E8. 

The customer request, instead of being for sales, may be an RMA request. 
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Information is then input from El to an RMA module. A reverse process in then 
executed, begun by an RMA number being communicated to the customer. In the 
typical case, the customer then returns merchandise authorized for return. The 
returned merchandise is received (entry point E3) in conjunction with the RMA 
module and receiving information portion of the assembled information. The 
RMA module communicates with the GL module so that appropriate accounting 
entries may be made. 

The effect of the overall business process is two-fold. First, a response to 
the customer's input is produced and communicated back to the customer. Second, 
during the course of the business transaction, a wealth of historical data are accu- 
mulated that may then be subjected to factual analysis for purposes of ensuring 
customer satisfaction, evaluating employee performance, and evaluating vendor 
performance. 

In the following description, the course of an order will be described within 
each of the domains identified in Figure 3, as follows: in the product domain, from 
quote to shipment, as well as return (although rather atypical, returns are neverthe- 
less a common occurrence); in the payments domain, from invoice to payment 
(both customer and vendor); in the financial performance domain, from cashflow 
to financial statements; and finally, in the factual performance domain, from 
parameters such as time, quantity and dollar volume to individual and group 
employee performance. 

Sales 

As may be appreciated from the foregoing description, an order may be 
preceded by a quote. Quotes may be requested and orders may be placed in writing 
(e.g., by fax), verbally (e.g., by phone), or electronically via the Web. More gener- 
ally, order information may be conveyed by electronic means (e.g., Internet, intra- 
net, EDI, satellite, remote terminal direct-dial), human-mediated 
telecommunications (e.g., email, phone, fax), or by physical means (letter, visit, 
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etc.). Regardless of the origin of the quote or order, the quote or order becomes a 
sales record. 

A screen display that may be used to view sales records is shown in Figure 
60. Quotes are each assigned a Quote number having a "Q" prefix. Orders are 
tracked via records referred to as "Master Work Sheets" (MWS), A Master Work- 
sheet contains all of the vital information related to an order. As seen in Figure 60, 
orders are each assigned a MWS number having a MWS prefix. The screen display 
of Figure 60 includes a status column in which the status of each quote and order is 
indicated, e.g., WebSubmit, WebQuote, Purchasing, etc. The status of each record 
can therefore be readily ascertained and tracked. 

Referring to Figure 61, the input layout of a quote is shown. During record 
input, the system prompts the user at every opportunity. For example, when the 
cursor is placed within the customer field, a list of previous customers is displayed. 
Assuming the customer is a repeat customer, the user can select the customer from 
the list. Various fields are then completed from information previously stored for 
that customer. 

To add an item to a quote, the user clicks the icon, followed by the "Go 
Prod" button. The Products file is then displayed, as shown in Figure 62. The Prod- 
ucts file may contain hundred of thousands or even millions of product records of 
products from different vendors. When the user selects a product, the all of the rel- 
evant information for that product is transferred to the quote. To facilitate selec- 
tion, the product file may be searched in various ways, e.g. by vendor, product 
category, etc. By searching the products file by manufacturer part number, the ven- 
dor offering the best price for a particular product may be identified. 

When all items have been added, the user is asked to specify partial ship- 
ment status. The partial shipment status specifies what items, if any, can be 
shipped separately and what items, if any, are required to be shipped together. The 
user is further prompted to enter installation information and to ensure that all 
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required cables, brackets, etc. have been ordered. In the case of computer equip- 
ment, for example, installation may involve installing a card or installing memory 
within a computer, loading software, etc. If installation is specified, installation 
charges are automatically added to the quote. 

During the foregoing process, the user may enter notes within a screen 
6101 . This screen is displayed whenever the quote or MWS is displayed. If a quote 
is created on the Web, a separate notes screen is provided for customer notes. A 
corresponding notes screen for internal use only is provided for all quotes. 

When the quote is satisfactory, the user may then save the quote by press- 
ing the post to purchasing button. 

To ensure that a quote is correct, one or more additional review stages may 
be required before the quote is converted to an MWS for purchasing. For example, 
the quote may be reviewed by "inside sales" to make sure that any compatibility 
requirements have been met and that, from a technical viewpoint, there are no 
errors in the quote. In a further review stage, the quote may be compared to a paper 
purchase order, if one exists, to make sure there are no discrepancies. When the 
quote has passed whatever level of review is required, it is then marked reviewed 
and converted to an MWS. The format of an MWS is shown in Figure 63. 

Note that, during the foregoing process, different people may have differ- 
ent limited privileges. Also, throughout the foregoing process and throughout the 
system generally, at each information entry point, the user's input is checked for 
accuracy in order to prevent common mistakes from occurring. 

PRIS (Purchasing, Receiving, Installation, Shipping) 

Purchasing, receiving, installation and shipping functions are closely inter- 
related. For this reason, preferably the output display/user interface presented dur- 
ing these different processes preserve a common look and feel. 

Purchasing may be based on a real inventory model, a virtual inventory 
model, or a combination of the two. In the case of the virtual inventory model, 
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automating purchasing functions in such as manner as to 1) scrupulously avoid 
physical inventory; and 2) achieve business scalability, becomes a challenge. The 
following description assumes that purchasing is based at least in part on a virtual 
inventory model. 

A simplistic approach to purchasing is to treat each customer purchase 
order separately. Under this approach, however, the amount of work involved in 
purchasing is proportional to the number of customer purchase orders; business 
cannot achieve 100, 200 or 1000% growth in a short period of time without caus- 
ing severe growing pains. 

Instead, the purchasing module of the present system is designed for busi- 
ness scalability and maximum automation, allowing for dramatic growth without a 
dramatic increase in human effort and with little or no pain. Scalability is achieved 
by "commingling" customer orders in such as way that what appears to an outside 
vendor as a single large order is tracked within the system as a multitude of smaller 
orders. 

Referring to Figure 64, purchase order sales actions result in MWS records, 
each MWS record including all of the relevant information required for purchas- 
ing. In an exemplary embodiment, this information includes internal MWS num- 
ber, customer P.O. number, sales cost, sales price, vendor, part number, 
manufacturer, manufacturer part number, installation grouping (within a particular 
MWS), shipping instructions, and stock/inventory status. Each MWS is assigned a 
unique MWS number which is used throughout the life of a transaction to differen- 
tiate distinct purchase orders. Any unique identifier may server the same purpose, 
including, for example, a material code number, a purchase requisition number, 
etc. 

The design of a purchasing output display/user interface greatly simplifies 
the purchasing process. For each item to be purchased, a record is displayed 
including each of the foregoing pieces of information. Preferably, all of the head- 
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ing allow for sorting on that heading. Furthermore, all items are selectable and 
may be expanded (by doubling clicking) into item details. 

The user interface allows a variety of actions to be performed, including 
grouping items within the display, removing items from the display, cancelling or 
changing various aspects of an order, holding an item or splitting an item (e.g., in 
order to hold less than all of the items details belonging to an item), etc. In an 
exemplary embodiment, items may be grouped by stock status (B/O, short stock), 
by shipping instructions (partial shipment OK, no partial shipment), by vendor, by 
manufacturer, by MWSs including addendums, etc. Groups of items may be 
removed from the display, including any of the aforementioned grouping and 
install groups. An item sold (one or multiple physical items) may be removed or an 
item detail (a single physical item) may be removed. Cancellations and changes 
may be made to an item sold, an MWS, shipping method, and freight charges. 

In accordance with the virtual inventory concept, items within a group (an 
installation group or a ship group, for example) are acted upon as a group. For 
example, if one of the items is removed from the purchasing screen (purchase of 
the item is delayed), all items in the group are removed from the display. Undes- 
ired inventory is therefore avoided. Otherwise, an item might be ordered and 
received only to find that it must be installed with or ship with an item that is back 
ordered. Valuable cash is then tied up in inventory waiting for the back-ordered 
item. The present system avoids such unwanted inventory. 

In a typical scenario, a purchaser's work might proceed in the following 
manner. 

1. Get all unfinished and new work (all items having no order date). 

2. Select a subset of items to work and remove all other items from the 
output display. 

3. Get all back ordered items and purchase them first. Eliminate related 
"no partial' 1 items from the output display until the corresponding back- 
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ordered item has been received. 

4. Group items from different orders and possibly change vendor on some 
items to obtain quantity discounts, if possible. 

5. Place order and repeat. 

In a preferred embodiment, at least the latter two steps are performed via 
the Web or with information obtained via the Web. Orders may either be placed 
directly or posted for bid by interested vendors. Furthermore, in accordance with 
supply-chain management functions described more fully hereafter, a single pur- 
chase may be "broadcast" via the Web to all relevant vendors and manfacturers 
within a supply chain for that product. 

Various user interface buttons relate to the actual placing of a purchase 
order. In a telephonic transaction, purchase cost (Pcost) on an item might be nego- 
tiated downward below the sales cost (Scost). By selecting an item and clicking on 
the button, the purchase cost may be input in the course of placing the order. A 
sales confirmation number may also be input by clicking on the corresponding but- 
ton. An automatically generated PO number may be assigned by clicking on but- 
ton. By clicking on the button, the output display is refreshed to remove from the 
display items that have been ordered. Simultaneously, the system marks the 
ordered items as ready to receiving, thus preparing the items for receiving. 

More preferably, purchase orders, instead of being placed manually, are 
placed electronically by linking to the seller's network of vendors. Automated pur- 
chasing may occur continuously or at regular intervals using "pull" technology, 
"push" technology, some combination of the two, or some other information 
retrieval technology or combination of technologies. 

Business rules guide the user to follow a pre-established routine for easily 
accomplishing complex business tasks including purchasing. Note, however, that 
dynamic workflow allows an experienced user with the requisite access authority 
to override business rules in order to handle new business requirements. This 
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authority is in turn counter-balanced by various consistency checks throughout the 
system that ensure accountability. 

Business rules implemented by the purchasing process include the follow- 
ing: 

1 . Items cannot be ordered before a quote is converted to a MWS. 

2. Duplicate orders are not allowed by item or MWS. 

3. Items can only be ordered from approved vendors. 

4. Purchasing can only be done by authorized personnel. 

5. Purchasing notes can only be viewed by authorized personnel. 

6. Purchase costs can only be viewed by authorized personnel. 
Referring to Figure 65, purchasing information, derived from MWSs, is 

used in the receiving process. (An item must have been purchased to be received.) 
Returns (RMA) information, also derived from MWSs, is also used in the receiv- 
ing process. (Return items must be received in order to give credit.) 

When the receiving process is begun, only items sold having an order date 
but no receive date are displayed. Double clicking on a item causes specific receiv- 
ing instructions for that item to be displayed, as described more fully hereinafter. 
The display format is very similar to that of the purchasing process. The possible 
actions that may be initiated, however, are particular to receiving. Those actions 
include 1) input actions; and 2) display actions. 

Information input during receiving includes packing slip number, serial 
number (each physical item, where applicable), carrier, quantity, payment terms, 
number of boxes, condition upon receipt, etc. Batch input for all packing slips and 
items. The system automatically matches input with items that exist in the system 
such that the same item cannot be received twice, the wrong item cannot be 
received, a cancelled order cannot be received, etc. 

Expected to receive will exclude refusal items. For example, a customer 
may change his or her mind after an order has been placed but before the item has 
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been received. In this instance, a refuse instruction may be placed on the item to 
prevent it from being received. 

As in the case of purchasing, in the case of receiving also, great benefit is 
obtained from allowing vendor access via the Web to see what products order from 
that vendor have been received. The vendor then obtains the information it 
requires to be truly responsive to its customer's needs. 

Referring to Figure 66, installation is based on the same type of output dis- 
play. However, only installation groups are shown. Items requiring no installation 
are not displayed. Furthermore, the user has the option to show all items requiring 
installation or to show only items requiring installation that have been received. 
The possible actions that may be initiated include 1) actions used to track installa- 
tion in various different stages of completion; and 2) input actions, namely input of 
serial number and asset tag number. (Asset tag numbers may be affixed by prear- 
rangement with the customer and retained in the system indefinitely to assist the 
customer in accounting for equipment.) 

An installation, once begun, may have several possible outcomes. In the 
typical case, the installation will be completed successfully and the installation 
group may be released for shipment. In other instances, installation may be only 
partially completed — e.g., manufacturer technical support may be required, addi- 
tional parts may be required to complete installation, or additional installation may 
be required for some other reason. In some instances, the appropriate action may 
be disinstallation, for RMA purposes or for some other reason. All of these differ- 
ent stages of completion are tracked within the system. 

Referring to Figure 67, the shipping process, like receiving, uses both pur- 
chase information and RMA information. The output display displays only items 
sold having a received date but no ship date. Double clicking on a item causes spe- 
cific shipping instructions for that item to be displayed, as described more fully 
hereinafter. Input actions that may be initiated include inputting a shipping track- 
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ing number, serial number (if not previously entered), customer specific number or 
asset tag number, claim value, carrier (or will call, which causes a local sales tax 
rate to be applied), payment terms, boxes, etc. Provision is also made to display 
only those items expected to ship, excluding refusal items, hold items and items 
with COD/cash terms. 

Referring to Figure 68, throughout the foregoing processes, and in particu- 
lar receiving, installation and shipping, notes conveying instructions regarding 
specific items may be displayed by double-clicking an item to cause a item detail 
display to appear. Included within the item detail display are several notes boxes, 
including boxes for unique installation notes, standard default notes from the cus- 
tomer file, unique shipping notes, standard default shipping notes from the vendor 
file (for RMA), RMA installation notes, receiving notes, etc. 

The PRIS output display also includes an "Expedite" view, shown in Fig- 
ure 69. The expedite function is to minimize delay in receipt of ordered products. 
Expedite actions include entering the Estimated Time of Arrival (ETA) of a prod- 
uct based on contact with the vendor and/or shipper and marking items in accor- 
dance with various expedite categories, as well as entering notes if necessary 
concerning the problem and expected solution. 

In accordance with one embodiment of the invention, expedite information 
may be brought up from the MWS screen, as shown in Figure 70. In Figure 70, a 
radio button has been clicked to cause a Not Received Report to be displayed. This 
report shows percentage of order completion in terms of ordering, receiving and 
shipping, as well as the age of the order in days. Various filtering options are pro- 
vided. Expedite status for each item may be entered by clicking on one of a large 
number of status buttons, e.g., "Urgent," "Wrong Product " etc. A Not Shipped 
report screen display is shown in Figure 71. 

Expedite status may also be set using a more abbreviated expedite pop-up, 
shown in Figure 72. 
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Figure 145 through Figure 149 show different output displays tailored for 
purchasing, receiving, installation and shipping in accordance with another 
embodiment of the invention. These output displays are different views of the 
same underlying data stored in the Item Detail records — the basis "currency" of 
the system. 

Figure 145 shows a purchasing output display. Various columns are com- ' 
mon to all of the PRIS output displays, e.g., MWS number and date, internal PO 
number, customer name and PO number, item description, etc. Columns of partic- 
ular interest for purposes of purchasing are Scost/Pcost (expected cost at time of 
sale and actual purchasing cost), Vendor/Confft, MfrVVendor part number (PN), 
Lprice/Lcost (the last sales price and purchasing cost for this item), Rebate, Spe- 
cial, and Pcomments, or purchasing comments. 

Figure 146 shows an Expedite output display. Of particular interest for pur- 
poses of expediting are Order/ETA (expected time of arrival at the time of order), 
Epd ET A/Status (latest ETA, reason for delay, etc.) and Epd Condition. 

Figure 147 shows a Receiving output display. Of particular interest for pur- 
poses of receiving is Receive Condition. 

Figure 148 shows an Installation output display. Of particular interest for 
purposes of installation are Install/Date and Install Group. Items within a same 
install group are to be installed together to form a single functional product or 
assembly. 

Figure 149 shows a Shipping output display. Of particular interest for pur- 
poses of shipping are Order/Reed and Ship Group. Items within a same ship group 
are to be shipped together. 

As with both purchasing and receiving, preferably vendors are given access 
via the Web to expedite information relating to that vendor. 

The foregoing principles explained in relation to PRIS may be adapted to 
other businesses in which, instead of installation, any type of transformation may 
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be performed. In channel assembly, for example, parts are assembled into a prod- 
uct mere days or even hours before the product is shipped to a customer. The trans- 
formation may therefore be assembly instead of installation. In other businesses, 
the transformation may be quite different, e.g., testing, burning-in, mixing, aging, 
curing, machining, etc. The transformation may be a single-step transformation or 
a multiple-step transformation in which intermediate products are produced. What- 
ever the nature of the transformation, information concerning what materials have 
been transformed, various stages of transformation, etc., are tracked in the data- 
base. The purchasing, shipping and receiving functions described previously there- 
fore become part of a comprehensive materials management system. 

RMAs 

Normally, the order will be successfully shipped to and received by the 
customer, who would then begin to use the products. In some instances, however, 
the product may not work as intended, the product may be lost or damaged in ship- 
ping, duplicate products may be shipped, or the customer may change his or her 
mind, necessitating that a product be returned. Returns are provided for through a 
Return Merchandise Authorization (RMA) mechanism. The same mechanism may 
be used for other account adjustments other than actual returns, for example freight 
adjustments, etc. In fact, in some sense, the RMA mechanism may be regarded as a 
garbage can of sorts — any action that is later found to be incorrect, for any reason, 
can be reversed through the RMA mechanism. Furthermore, the existence of an 
RMA has immediate effect throughout the system, on purchasing, receiving, 
installation, shipping, accounts payable, and accounts receivable. For example, if 
an RMA is received and the corresponding vendor invoice has not yet been paid, 
the vendor invoice will not be paid until the return product is received and shipped 
back to the vendor and a credit received from the vendor. The immediacy of the 
effect of creating an RMA is achieved through the use of a central underlying 
table — item detail — that functions as the building block upon which other tables 
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depend. In essence, most data is viewed within the system simply as a "window" 
into the item detail table. 

An RMA may also be used for warranty replacement parts. This feature, 
coupled with Web access, allows customer's to track replacement parts themselves 
without contacting a technician or service representative. A customer may request 
an RMA in any of the ways previously described for obtaining a quote or placing ' 
an order. When an RMA request is received, an RMA record is created. An RMA 
screen display is shown in Figure 73. 

Referring again to Figure 63, a MWS display includes an RMA button. 
When this button is clicked, the user is prompted to select an item from the dis- 
played MWS for return. An Add RMA Record screen display such as that of Fig- 
ure 74 is then used to specify return type, reason, etc. A typical RMA has two 
"sides," the customer side and the vendor side. When the item to be returned is 
selected, preferably both the customer side and the vendor side are filled out by the 
system. Any changes may be made from a screen display such as that of Figure 75. 
By clicking a button, the screen display of Figure 75 allows for display of the cus- 
tomer side only, the vendor side only, or both sides of the transaction, as well as 
claims information. 

A return may be made for any of a number of different reasons. Different 
return types are therefore defined. Depending on the return type, some RMA fields 
will not be applicable. Preferably, the system is provided with sufficient intelli- 
gence to automatically fill in these fields as "N/A 

As shown in Figure 76, a lookup table may be used complete various fields 
of an RMA record based on the selected return type. If a return is for credit, for 
example, then return type 1 is the corresponding return type. Depending on 
whether payment was by check, credit card or credit memo, different fields may be 
applicable. In the present example, however, the mode of payment does not affect 
the manner in which the RMA is completed. As noted previously, an RMA has 
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both a customer side and a vendor side. In Figure 76 therefore, each table cell has 
an upper half corresponding to the vendor side (V) and a lower half corresponding 
to the customer side (C). To take a few example fields, in the case of a return for 
credit, no replacement product is called for, hence the Repl MWS column is 
marked N, for no. Since no replacement product is expected, then on the vendor 
side, the Rec'd column is N/A, and on the customer side, the Ship column is N/A. 
Similar logic dictates the way in which the remainder of the table is completed. 

Similar logic tables may be used to automatically approve RMAs and pro- 
vide an RMA number instantaneously for most RMA requests. Again, approval 
has a customer side and a vendor or manufacturer side, at least in the case of a vir- 
tual inventory model. (RMAs eliminate, or at least minimize, the hazard of accu- 
mulating obsolete inventory as a result of returns.) In an exemplary embodiment, a 
series of limit checks are performed on an RMA request. Referring to Figure 77, a 
limit file is shown, having a customer portion, a vendor portion and a manufacturer 
portion. Assume once again that the return type is return for credit, and assume 
further that the payment mode was check. The first column has a Y value, indicat- 
ing that automatic approval of RMAs of this return type are allowed. The next 
three columns relate to the manufacturer and contain the values Y, Y and N, 
respectively, indicating that for the RMA to be approved the manufacturer must 
allow returns, that the manufacturer must further allow open box returns, and that 
the time to RMA cannot exceed the manufacturer's allowed maximum time dura- 
tion. For a particular manufacturer, the manufacturer's specific return policies are 
stored in a table such as that shown in Figure 78. 

Referring again to Figure 77, the next two columns relate to vendor and 
contain the values N and N/A, respectively, indicating that the time to RMA can- 
not exceed the vendor's allowed maximum time duration and that the vendor's 
restocking fee policies are not applicable for this type of return. For a particular 
vendor, the vendor's specific return policies are stored in a table such as that 



WO 99/33016 



62 



PCT/US98/27496 



shown in Figure 79. 

Referring again to Figure 77, the next four columns relate to customer and 
contain the values N, N, N and N/A, respectively, indicating that the time to RMA 
cannot exceed the maximum time duration allowed for this customer, that there 
must be no restocking fee, that the sales price cannot exceed the maximum allowed 
for this customer, and that customer service fee policies are not applicable for this 
type of return. For a particular customer, specific return policies for that customer 
are stored in a table such as that shown in Figure 80. 

If an RMA request meet all of the applicable automatic approval criteria, 
then it may be automatically approved, instantly, and an RMA number communi- 
cated to the customer as shown, for example, in Figure 81 . 

A more detailed listing of RMA types, subtypes and conditions is provided 
in Figure 159. 

Business rules implemented by the RMA module include the following: 

1. RMAs can only be created for items shipped to customer. 

2. One item per RMA (quantities are OK). 

3. Replacement Quotes are created by the user specifying the appropriate 
replacement product. 

4. Generation of printed/faxed RMAs with Return packing slips for cus- 
tomer use. 

5. Receiving can only receive items from customers with valid RMA 
issued. 

6. Wrong or defective products automatically create RMAs. 

7. Replacement MWSs can only be shipped after being released by pur- 
chasing. 

8. Vendor RMAs must have vendor RMA numbers before shipping. 

9. Complete control of RMA module by executive group. 
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One characteristic feature of the present system perhaps most evident in 
relation to RMAs is the display of information in a very complete way and in such 
a manner as to allow ready interaction. In conventional database applications, 
information is presented in simple row format within an output display. Multiple 
levels of "drill-down" may be required to display a particular detail. Furthermore, 
entry or manipulation of information can typically only be performed from a sepa- 
rate input screen. 

In the case of the present system, by contrast, as exemplified by the RMA 
display of Figure 73, records are presented in a very information-rich format. 
Entry or manipulation of information is enabled within the same screen display. In 
the case of RMAs, for example, a user with the proper authority is able to approve 
or cancel an RMA, change an RMA to a different type, release a replacement ship- 
ment, etc. 

A further important feature also greatly facilitates convenient navigation 
and ease of use. In most systems, to display related records, a search editor is used 
to enter a search. In the present system, by contrast, a "related-switch" menu bar is 
provided within most displays. Using this related switch feature, a user may select 
one or more records within the output display and select a related file from a pop- 
up of related files. The system then searches in the related file for records related to 
the selected records and displays the related records in the output display fonmat of 
the related file. In the case of RMAs, for example, the related switch capability 
may be used to switch to related customer invoices, vendor invoices, credit 
memos, etc. One file may be related to another file but only indirectly, through a 
third file. In this instance, an intermediate search is required, the results of which 
are not displayed. Of course, the number of intermediate files may be more than 
one. 

Preferably, vendors are given access via the Web to RMA information per- 
taining to them. A vendor may then immediately provide an RMA number without 
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requiring any human intervention. 

With vendor access to purchasing information, receiving information, 
expedite information and RM A information pertaining to that vendor, a truly inte- 
grated supply chain results. Such an arrangment makes global commerce just as 
convenient as local commerce. For example, a seller may have ten or hundreds of 
vendors worldwide, many in locations where the time difference would ordinarily 
make doing business difficult and tedious. Such difficulty is removed in the case of 
the present system, because all of the intelligence needed to do business resides in 
the system and is readily accessible at each party's convenience wherever in the 
world that party may be. 

As previously described in relation to PRIS, the present single-database 
system contains information about installation and product configuration. This 
information may be used to advantage to avoid a common problem encountered in 
relation to RMAs. When a product is returned that has other add-on products 
installed, the user may forget to remove these add-on products before shipping the 
product to be returned. For example, a printer may have installed a memory 
upgrade and a network card. If the printer is returned to the vendor with the mem- 
ory upgrade and the network card installed, there is some likelihood of the memory 
upgrade and network card being removed during service and not re-installed. 
These add-on products may then become lost. 

To avoid this problem, when an RMA is requested for a product that has 
had one or more add-on products installed, a dialog is displayed to the user 
reminding the user to remove the add-in products prior to shipping back the prod- 
uct. The same reminder may instead, or in addition, be sent by e-mail, fax, etc. 

The PRIS capabilities described previously may also be used to advantage 
to track RMA status and display status information via the Web. The stages of an 
RMA typically include some or all of the following: 1) shipped from customer to 
reseller; 2) received by reseller; 3) shipped by reseller to vendor; 4) received by 
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vendor; 5) shipped by vendor, 6) received by reseller from vendor; and 7) shipped 
from reseller back to customer. With the possible exception of number 5, status 
information with respect to each of the foregoing stages is available within the 
database or, in the case of number 4, through conventional electronic tracking ser- 
vices offered by carriers such as UPS, Federal Express, etc. 

Design Philosophy: Self-Correcting Knowledge-Based System 

The information-rich action-oriented displays previously mentioned are a 

manifestation of a design philosophy in which a system knowledge base is contin- 
uously expanded with user assistance and reflected in the manner in which users 
interact with the system. Other manifestations of this design philosophy are found 
in the options described previously (Table 1 and Figure 124 through Figure 128) 
and the experiential constraints alluded to previously and described in greater 
detail hereinafter. Referring to Figure 129, a knowledge base is initially created 
based on system analysis and design considerations, considering the range of pos- 
sible outcomes at each stage of the business process, and considering further the 
goal of total automation, phones free and paper and pencil free. These system anal- 
ysis and design consideration will necessarily be incomplete — hence the need for 
dynamic workflow. No pretense is made that a single predetermined workflow 
definition will prove adequate in practice. 

The knowledge base affects user interaction with the system through two 
different kinds of displays, a data input display and a process display. The data 
input display is used to actually enter data into the system. During the course of 
data entry at entry points E1-E9 (Figure 59), rigorous entry qualification occurs to 
eliminate errors. In the case of PRIS, for example, during receiving, only ordered 
items are allowed to be received. To cite a further example, during vendor invoice 
entry, described hereinafter in relation to Figure 121 through Figure 123, the sys- 
tem detects an attempt to enter a duplicate invoice number and prevents the dupli- 
cate from being entered. The process display is used to act on the data within the 
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system to move an item to the next stage, and in the course of such action has the 
effect of changing the status of records acted upon. In the case of RMAs, for exam- 
ple, the user may easily, with the click of a button, approve or cancel an RMA, 
issue a customer credit memo, change the N/A settings of the RMA, etc. In the 
case of expedite, the user may easily, with the click of a button, record the reason 
that a product has not been received. To cite further examples, in the case of ven- 
dor invoices and customer invoices, described hereinafter, the user may easily, 
with a click of a botton, mark a vendor invoice for approval or cause an aging 
report window to be displayed for customer invoices. 

The knowledge base and the application of it to data input and user actions 
is what makes an automated, end-to-end, sequential business process possible. 
Depending on the skill level of the user, the user is given some level of authority 
ranging from minimum authority to maximum authority. For users with minimum 
authority, the system ensures that work gets done in a prescribed, correct manner. 
For users with greater authority, dynamic workflow provides myriad additional 
possibilities while maintaining accountability. 

During use of the system, unanticipated circumstances are bound to arise in 
which the user cannot accomplish his or her task (or accomplish it as well) in a 
phones free, paper and pencil free manner using the current features of the system. 
In this event, the knowledge base of the system is then added to to solves the user's 
problem. In some instances, the user may be able to add to the knowledge base 
directly. For example, the user may wish to add a further return type by adding an 
entry to the table of Figure 75. Similarly, in the case of factual performance evalu- 
ation, described hereinafter, the user may choose different performance metrics or 
combinations of metrics to be tracked and displayed. In other instances, adding to 
the knowledge base may require administrative intervention. In the case of the 
options of Table 1 and Figure 124 through Figure 128, adding further options may 
require the efforts of a programmer. 
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Having described for an order the course of events in the product domain, 
the course of events in the payments domain will now be described, first in relation 
to sales tax and sales commissions, then in relation to customer payments and 
finally in relation to vendor payments. 

Sales Tax and Sales Commissions 

Sales tax and sales commissions are automatically computed and stored in 

the system based on applicable tax rates and commission rates. 

In the case of sales tax, a sales tax table contains state tax rates and local 
tax rates. For a particular sale, the applicable tax rate is determined based on the 
ship-to address. Typically, preliminary tax payments are made each month and a 
final tax payment is made each quarter. Sales tax records are automatically added 
to a sales tax register (first prepayment, second prepayment, or final quarterly pay- 
ment) for the appropriate period. As shown in Figure 82, the sales tax module 
automatically calculates the figures to be entered on each line of a sales tax return, 
or may be programmed to print out the actual return. 

In the case of commissions, commission rates are stored within a Sales Rep 
file and a Sales Support file. Because each order is worked on by both outside sales 
and inside sales, each order will typically have two commissions. Commission 
records are created at the time a customer invoice is issued. Commissions are then 
approved and scheduled to a commission register for payment in a similar manner 
as accounts payable, described hereinafter. Multiple levels of commissions are 
provided for. A simple example of multiple commissions is where an outside 
salesperson responsible for customer interface is supported by an inside salesper- 
son that reviews orders for correctness and troubleshoots the order, if necessary, 
during the fulfillment process. In more complex organization structures (e.g., 
multi-level marketing), the number of commissions may be greater than two. 

Accounts Receivable 



WO 99/33016 



68 



PCT/US98/27496 



When an order is shipped, a customer invoice is automatically issued, i.e., 
entered into the computer system. If paper invoices are required, then at regular 
intervals (each day, for example) an accounts payable clerk prints out, checks and 
mails customer invoices issued during the preceding interval. (Alternatively, the 
printing and mailing of customer invoices may also be automated.) In an exem- 
plary embodiment, invoices are issued using the "Issue invoices" option within the 
customer invoice file. A customer invoice screen display is shown in Figure 83. 
With the passage of time from the invoice date, invoices pass from one category to 
another, e.g., 30 days, 60 days, 90 days, etc. At any time, the accounts payable 
clerk may view invoices within different categories. Also, as is the case with other 
output screen displays, the user is able to manipulate information and interact with 
the system, e.g., to analyze an account, add a comment or note, etc., all without 
paper and pencil. 

Referring more particularly to Figure 84, from a MWS output screen dis- 
play, the user can select a group of invoices and click on a collections button to 
cause a collections summary to appear. By further clicking on a By Customer but- 
ton, the selected invoices are broken down by customer as shown in Figure 85. 

When a customer payment is received, a payables clerk clicks an add 
record button to add a customer payment record. The clerk is then presented with a 
pick list of customers. The clerk selects the customer from which the payment has 
been received. The customer is then prompted in turn to enter the mode of payment 
(check, cash, etc.) and the payment date. A customer payment record such as that 
shown in Figure 86 is created. A payment may correspond to multiple invoices. 
The clerk enters from the check stub reference numbers and invoice numbers, as 
well as the respective amounts, for each invoice (or credit) to which the check pur- 
portedly applies. Referring to Figure 86, for example, the check #429069, as indi- 
cated on the check stub, pertains to five different items, or reference numbers, the 
first three of which are invoices and the last two of which (DM32890/4829 and 



WO 99/33016 



69 



PCT/US98/27496 



DM32889/4695) are credits. 

After the reference and invoice numbers have been entered from the check 
stub, the system attempts to match the entries to the corresponding invoices within 
the system. The clerk is prompted to enter the type of each item (e.g., invoice or 
credit) and the amount indicated on the check stub. The system then checks to see 
if the amounts indicated coincide with the expected amounts stored within the sys- 
tem and indicates each item as being reconciled or not reconciled. The clerk then 
saves the record, which may then be approved and posted by supervisory person- 
nel. 

Discrepancies may occur between payment amounts and invoice amounts, 
i.e., both overpayment and underpayment may occur. An OverUnderPay file is 
used to track and resolve such discrepancies. An OverUnderPay screen display is 
shown in Figure 87. A corresponding record detail screen display is shown in Fig- 
ure 88. OverUnderPay is an example of dynamic workflow and allows for the 
application of user discretion in handling overpay and underpay situations given 
the requisite authority. 

Business rules implemented by the A/R module include the following: 

1 . Invoices will be automatically created on shipment of products to cus- 
tomers. 

2. Items can only be invoiced once. 

3. Invoices must be issued by accounting before they are valid. 

4. EDI invoices are provided for. EDI invoices will automatically be sent 
via EDI. 

5. EDI invoices PID numbers must match PO PID numbers in the EDI file, 

6. Customer invoice numbers indicated on the check stub must match with 
existing customer invoice numbers in the system. The amounts must 
correspond, else an overpay/underpay records is created as described 
above. 



WO 99/33016 



70 



PCT/US98/27496 



Customer Collections 

An important object of the present system is to allow routine operation of 

an entire business without paper and pencil. In the course of performing a business 
function,, a person will typically gather information from various sources and jot 
down the information for reference while performing the business function. This 
reliance on paper and pencil is perhaps most apparent in the area of customer col- 
lections. Every invoice to be collected presents a different situation, as does every 
customer. Previous contacts with the customer may need to be followed up on, or, 
conversely, the customer may become annoyed at too frequent contact 

The present system overcomes these problems by providing a highly- 
usable customer collections "environment." Referring more particularly to Figure 
141, the customer collections environment is shown within the bottom portion of 
the screen. Within the top portion of the screen is displayed a Customer Invoice 
output display showing selected invoices of a particular customer. 

The customer collections environment within the bottom portion of the 
screen is composed of various different panels. A "Get" panel presents aged A/R 
information and allows the user to retrieve invoices within the different age cate- 
gories. Pressing "Get" for a particular category causes the corresponding invoices 
to be listed within the Invoice panel to the left, from which the user can select a 
particular invoice for display. 

The "Get" panels also provides a get Problem/Tickler option. Each invoice 
may be marked with one or more problems and/or one or more ticklers. When an 
invoice is selected, problem codes representing problems associated with that 
invoice are displayed within a Problems list box. Similarly, ticklers associated 
with that invoice are displayed within a Tickler Log. The user can add and remove 
problems and ticklers to and from an invoice as appropriate. 

A Contact Log is used to record contacts and attempted contacts with the 
customer. For example, if the customer says "Please don't call again for six 
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weeks," this information can be recorded in the Contact Log. Below the Tickler 
Log is located a financial summary of the current selected invoice. Below the Con- 
tact Log is located payment details of the current invoice. Below the financial sum- 
mary panel are located text box for invoice-specific notes and invoice-specific 
keywords. The ability to assign keywords to record and retrieve records using 
those keywords is provided for the user's convenience. Below the payment details' 
panel is located customer contact information, and to the right of the customer con- 
tact information is located a text box for customer-specific notes. 

In Figure 141, the user has selected a Get Problems option. As shown in 
Figure 143, a text box is then displayed listing various possible problems. To mark 
an invoice as having a particular problem, the user selects that problem and clicks 
OK. If instead the user selects Get Tickler, a text box as shown in Figure 144 is 
displayed listing various ticklers. To mark an invoice with a particular tickler, the 
user selects that tickler and clicks OK, 

Referring to Figure 142, the user may also search for invoices within par- 
ticular categories, regardless of whether a particular invoice has been marked as 
having a problem or not. The categories (e.g., "With addendums," "Replacements 
without credit memo," etc.) will typically have implications that affect collection. 
Dealing with categories of invoices in this manner increases efficiency. 

Because all of the relevant information needed to perform collection, 
including client contact information, is captured in the database and displayed in a 
readily-accessible and usable fashion, the collections function can be performed by 
a relatively unskilled worker following a minimum amount of training. Further- 
more, the collections function may be performed by one person one day and 
another person the next day without confusion or loss of effectiveness, minimizing 
the effect of sickness and/or employee turnover. 

Accounts Payable 

The accounts payable module is designed to ensure that invoices are timely 
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paid but to prevent double payment, overpayment, etc., and to systematically 
resolve problems with invoices so that they may be paid. The payment policy may 
be more or less aggressive. On the aggressive side, for example, the system may 
provide that a vendor invoice is paid only after a corresponding customer payment 
has been received, thereby assuring a stable cash flow. 

A vendor invoice screen display is shown in Figure 89. When vendor 
invoices are received, they are entered within a grid such as that of Figure 90. The 
invoice number and PO number are entered manually from the invoice. The payee 
and vendor are preferably selected from pick lists. The invoice date, total billed, 
tax and freight are entered manually from the invoice. For each entry within the 
Add Invoices screen, a vendor invoice such as that of Figure 91 is created. Based 
on the PO number, the system displays items sold from the MWS (with or without 
addendum, or possibly even multiple addendums) to which the invoice pertains. 

The vendor payment process begins by an accounts payable clerk invoking 
a Daily Vendor Verification option. Referring to Figure 92, this option identifies 
all of the open vendor invoices and runs them through a "sieve" to determine 
which invoices are "clean," i.e., fully reconciled, and which invoices are not clean, 
i.e., have discrepancies. Within each the categories clean and not clean, there are 
numerous sub-categories arranged in order from most important to least important. 
A given clean invoice may in fact fall within several sub-categories, but is catego- 
rized at any given time into the highest sub-category to which it belongs. Simi- 
larly, a given invoice that is not clean is categorized at any given time into the 
highest sub-category to which it belongs. By double clicking on a particular cate- 
gory, invoices belonging to that category are displayed. Typically, the payables 
clerk will pre-approve clean invoices for approval by supervisory personnel hav- 
ing authority to approve payment. Invoices that have been approved are then 
scheduled by the payables clerk to a payment register, an example of which is 
shown in Figure 93, for payment in accordance with their respective due dates. 
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For invoices that are not clean, the payables clerk displays invoices from 
the highest sub-category, investigates each invoice and attempts to fix the particu- 
lar discrepancy involved with that sub-category. The same approach is followed 
with the invoices of each sub-category in turn. The verification is then re-run. 
Some invoices may have become clean, whereas other invoices may have passed 
to a next-lower sub-category but may still not be clean. 

Referring again to Figure 90, prior to entering invoices, the user is 
prompted as to which type of invoices to be entered, including as one possibility 
freight bills. When a freight bill is entered, the user enters the invoice number, PO 
number, and payee (the latter from a pick list), and instead of a vendor list, picks a 
carrier from a carrier list. The user is then prompted to enter a date range specify- 
ing a period to which the freight bill pertains (Figure 94). Shipping records are 
then searched, and freight charges for shipments with the specified carrier during 
the specified period are totalled. Invoice entry is then completed in the usual man- 
ner. If the invoice amount entered from the invoice equals the expected total 
charges, then the resulting invoice record is marked reconciled. If not, then the 
invoice record is marked not reconciled. 

Qualification of user inputs, previously described, occurs at each entry 
point El -E9 of Figure 59 but is most readily illustrated with respect to invoice 
entry. Figure 121, Figure 122 and Figure 123, respectively, illustrate various warn- 
ing dialogs used to prevent entry of erroneous data. If entry of a duplicate invoice 
number is attempted, for example, a dialog such as that of Figure 121 is displayed, 
and the system refuses to permit the duplicate entry. If an attempt is made to enter 
the same invoice twice during an entry session, then a dialog such as that of Figure 
122 is displayed. If the system detects that the same invoice number has been used 
previously but with respect to an apparently different vendor, then the user is noti- 
fied (Figure 123) and may choose whether or not to proceed. 

Note that each item can have only one active customer invoice and one 
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active vendor invoice. This feature prevents may common AR/AP errors. For 
example, if duplicate vendor invoices are received in relation to a single item, only 
one of those invoices will be matched with the item record representing the physi- 
cal item. The other vendor invoice finds no place in the system. 

Business rules implemented by the AP module include the following: 

1 . Items can only be billed once by a vendor. 

2. Vendor invoices must reconcile with purchasing costs and terms 
(freight, tax, payment dates, etc.). 

3. No duplicate vendor invoices are allowed. A vendor invoice is identi- 
fied by a combination of vendor invoice number and MWS number. 
Hence, the same vendor invoice number may be billed against different 
MWS numbers (since some vendor's numbering systems may generate 
duplicate numbers), but not against the same MWS number. 

Vendor verification is merely exemplary of a more general methodology 
for accomplishing a business task. This more general methodology allows a user to 
perform a business task without the need to refer to different sources of informa- 
tion. In an exemplary embodiment, it involves the following steps: 

1 . A classification scheme is specified, consistent with common business 
practice and terminology. 

2. An algorithm is applied whereby items are classified, marked and dis- 
played according to category. 

3. Within a single display screen, the categorized items are displayed 
along with one or more user interface controls for taking action with 

respect to an item. 
The items may be items within any of the foregoing domains— products 
(e.g., computer equipment), payments (e.g., vendor invoices, customer invoices, 
payment registers), performance (e.g., accounts), or personnel (e.g., activity sum- 
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maries). Furthermore, the items may be single items or groups of items (e.g., mas- 
ter worksheets). 

Other exemplary uses of the foregoing methodology will be briefly 
described. Still others will be apparent to those of ordinary skill in the art. 

The items may be customer invoices and the business task may be collec- 
tions. The invoices may be classified into various classifications according to the 
reason for non-payment, e.g. never received, return requested, price discrepancy, 
etc. The items may be order items and the business task may be an expedite task. 
The items may be classified into various classifications, e.g., vendor lost order, 
(re)seller lost item, item damaged, wrong item, empty box, etc. The items may be 
master worksheets and the task may be purchasing. The master worksheets may be 
classified into various classifications, e.g., replacement MWS, addendum, internal 
use, etc. The items may be payment registers and the business task may be report- 
ing. The payment registers may be classified into various classifications according 
to payee, e.g., vendor, federal government, state government, local government, 
service providers, etc. 

Nightly or Periodic System Update 

In addition to the foregoing business rules, or experiential constraints, 

implemented within each of the individual modules, recall that cross-checks 
between various domains are performed at intervals. Such cross-checks may be 
performed nightly or at other periods of low system activity. When performed 
nightly, the cross-check routine may be referred to as a nightly update. As a result 
of the nightly update, a nightly update report is generated, all or selected portions 
of which are automatically emailed to responsible individuals for receipt the fol- 
lowing morning. An example of a nightly update report is provided as Appendix 
A. 



General Ledger and Real-time Financials 

Having described for an order the course of events in the payments domain, 
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the course of events in the financial performance domain will now be described. 

The most "tasking task" for most small- and medium-sized business is 
accounting. Accounting packages typically come in one of two flavors, packages 
for non-accountants that mask the complexity of generally-accepted accounting 
principles (GAAP) but do not provide information in "accountant-ready" form, 
and packages for accountants that are not readily understood or used by non- 
accountants. The need for real accounting documents coupled with the difficulty of 
producing them has necessitated considerable reliance on accountants, either out- 
side accountants or full-time paid staff If an outside accountant is used, the 
accountant brings the books up-to-date only at intervals. Even in the case of full- 
time paid staff accountants, the books are typically brought up to date only 
monthly, or at most weekly, because of the arduousness of the process. Typically, 
invoices are reviewed and confirmed, then manually posted, then a trial balance is 
run, adjustments are made, etc. 

Accounting information is presented in the form of financial statements. 
Information about each item appearing on the financial statements is gathered in 
an account. An account exist for each asset, liability, revenue, expense, and cate- 
gory of owner's equity of a company. More particularly, the classic accounting 
process involves the following steps: 

1 . Analyzing business and financial transaction to determine if they affect 
accounts; 

2. Journalizing transactions affecting the accounts; 

3. Posting journal entries to accounts; 

4. Determining the balance in each account using incoming bank state- 
ments; 

5. Preparing a total of all the account balances, called a trial balance; 

6. Determining whether any adjusting entries are necessary and journaliz- 
ing and posting such adjusting entries; 
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7. Preparing financial statements; 

8. Closing income statement accounts and establishing ending balances for 
use in the next accounting cycle. 

In classic accounting practice, the effects of a transaction are not recorded 
directly into the accounts. Rather, they are recorded in a journal entry in a general 
journal, or general ledger (GL). The process of transferring the information from 
the journal entry to the accounts is called posting. At the end of the fiscal period, 
before making any adjusting entries, an accountant prepares a schedule listing all 
the individual account titles and their respective debit or credit balances. Follow- 
ing the trial balance, various adjusting entries may be required to assure that reve- 
nues are reported in the period they were realized and that all expenses are 
matched with the revenues they produced. An adjusted trial balance is then pro- 
duced. Financial statements are generally prepared on worksheets from the 
adjusted trial balance. Whereas balance sheet accounts are permanent (or real) 
accounts, income statement accounts are temporary (or nominal) accounts. 
Because the data collected in an income statement account is only for the current 
fiscal period, the balance is not carried forward but is eliminated at the end of each 
fiscal period. The process of eliminating the balance in each of the revenue and 
expense accounts (by transferring the balance to a different permanent account) is 
called closing the accounts. 

As a result of the cumbersomeness of the foregoing process, management 
processes accommodate the limited availability of accounting-derived manage- 
ment information. In reality, however, the need for management information is 
constant and ongoing, and cannot be expected to synchronize itself to the availabil- 
ity of accounting information without sacrificing performance. 

The present software takes a different approach to financial performance 
activity. In contrast to typical practice in which an accountant gathers data from all 
departments and performs accounting functions after the fact, in the present sys- 
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tern, accounting functions are performed concommitant with data entry. Instead of 
manual posting of accounting entries, posting is automatic, either continuous or at 
user-specified intervals (e.g., nightly). For non-accountants, the complexities of 
accounting are hidden completely — users simply go about their usual activities of 
running the business. The automatic posting process, however, generates entries in 
GAAP format. Furthermore, instead of a limited number of "canned" reports, a 
GUI-based report-writer is provided that allows any kind of report to readily gen- 
erated, either on command or on schedule. At any time, a user may simply press a 
button and obtain a real-time, accurate financial report. 

Because posting is automatic, posted entries are not guaranteed to be cor- 
rect. (Because of the stringent qualification of user entries, however, errors are 
greatly minimized.) Therefore, unlike conventional accounting packages, entries 
are allowed to be modified. In the case of invoices, for example, invoices are 
allowed to be modified up until the time they are paid. As invoices and other 
records are viewed and modified, they are flagged to be checked by a centralized 
GL module to determine if the modification requires an adjusting entry. If so, the 
adjusting entry is made automatically alongside the original entry. 

Although in an exemplary embodiment the GL module is a centralized 
module, the functionality of the GL module may be distributed among the various 
modules so as to operate continuously. For example, an AR portion of the GL 
functionality would make general ledger entries immediately to reflect payment 
information as it is input, a purchasing portion would make general ledger entries 
immediately to reflect obligations as incurred through purchase orders, etc. 

To use the real-time financial capabilities of the present system, the user 
sets up accounts, then assigns accounts to different line items of records within the 
system. More than one account may be assigned to a line item. If only one account 
(i.e., a single default account) is assigned to a line item and an automatic posting 
option is selected, then the line item is automatically posted to that account 
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Default accounts are set up for various different files, such as AP, AR, cash, credit 
card transactions, commissions, payroll, etc., as shown in Figure 95. The manner 
in which these defaults are established will be described. 

Accounts are set up within a chart of accounts. The chart of accounts keeps 
a record of each account including the name of the account, type of account, 
account code, etc. To add an account, the user enters information about the account 
within an entry screen such as that of Figure 96. Whereas debits and credits are 
intelligible primarily to accountants, increasing and decreasing a balance are con- 
cepts easily understood by non-accountants. Hence, when an account is first estab- 
lished, a button is selected designating whether the account balance is increased by 
a debit or by a credit. Thereafter, user may use the more familiar concepts of 
increase and decrease. An exemplary chart of accounts display is shown in Figure 
97. Doubling clicking on a particular account results in a display such as that of 
Figure 98. The date of each transaction contributing to the balance is shown, 
together with an explanation, the journal reference number, and the amount. This 
screen display may be used to modify account information as necessary. 

For accounts receivable, a correspondence between line items on a cus- 
tomer invoice and specific accounts is set up through a customer setup display, 
shown in Figure 99. Generally speaking, each of the different list boxes corre- 
sponds to an amount that is (or is derivable from) a line item (or multiple line 
items) on the customer invoice or other record. The account or possible accounts to 
which the amount is to be or may be posted are specified by clicking the but- 
ton and selecting from a pop-up list of accounts of the appropriate type. If multiple 
accounts are selected, one may be selected as a default account, the effect of which 
is explained hereinafter. If for each list box only a single account is selected and is 
designated as the default account (using the Set Def button), then posting is auto- 
matic and is performed on a continuous basis or at regular intervals (e.g., daily). 
As a result, a truly up-to-date financial report can be run at any time. 
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Referring to Figure 100, an accounts receivable display is shown in accor- 
dance with an exemplary embodiment of the invention. For each customer 
account, there is shown the GL account to which balances are posted, the current 
account balance, and amounts 30, 60, and 90 days overdue, respectively. By dou- 
ble-clicking on a balance field, transactions records relating to that balance field 
are displayed. For example, double-clicking on the current balance of $2,712.75 • 
shown in Figure 100 results in a display such as that of Figure 101 , The date of 
each transaction contributing to the balance is shown, together with an explana- 
tion, the journal reference number, and the amount. 

Corresponding screen displays for accounts payable as those of Figure 99, 
Figure 100 and Figure 101 for accounts receivable are shown in Figure 102, Figure 
103 and Figure 104, respectively. 

If the setup of accounts indicates that an amount may be posted to more 
than one account, then manual account distribution is required. Referring to Figure 
105, a pop-up screen display used for this purpose is shown. The assigned 
accounts are displayed, and the user enters debits or credits for the accounts as 
appropriate. The effect of a debit or credit (increase or decrease in the account) is 
displayed as an aid to the novice user. 

Referring to Figure 106, a general journal display is shown in accordance 
with an exemplary embodiment of the invention. For each transaction there is dis- 
played a journal reference number, account titles and explanation, and posting ref- 
erence to the account codes of the accounts debited or credited as result of the 
transaction. Doubling-clicking on a particular account results in a display such as 
that of Figure 107. The date of each transaction contributing to the balance is 
shown, together with an explanation, the journal reference number, and the 
amount. 

As a result of the continuous, automatic posting activity described, once a 
financial report has been defined, it may be run at any time (or at scheduled times) 



WO 99/33016 



81 



PCT/US98/27496 



and is assured to be up-to-date. Moreover, it is verifiable, i.e., every supporting 
transaction may be readily retrieved and viewed. In an exemplary embodiment, a 
financial report is defined using a display screen such as that of Figure 108. The 
display follows a familiar spread-sheet-like format. For each line of the report, a 
line item description is entered. Then, in the appropriate column, the user enters 
either an account (by selecting from the chart of accounts pop-up), a calculation ' 
formula, or even the result of another report. When a report is run that requires the 
result of another report, that other report is run first. An actual report generated 
using the report definition of Figure 108 is shown in Figure 109. 

A report, instead of being the line-time type of Figure 109, may be a trend 
analysis report. Trend analysis provides a powerful tool for understanding inter- 
relationships between various aspects of a business. Referring to Figure 1 10, a 
trend analysis report is defined in similar manner as an ordinary financial report. A 
cell is selected and the user is prompted as to whether the cell contents is to be a 
local balance, a linked field (from another report), or a calculated field. In the illus- 
trated example, local balance is selected, and the user selects an account from the 
chart of accounts pop-up, in this instance Cash in Bank #1 . To investigate the 
inter-relation of different accounts, a further account would then be selected, say 
Trade Accounts Payable. Plot labels may be entered by the user that differ from the 
actual names of the accounts themselves. Referring to Figure 1 1 1, a trend fre- 
quency is then selected. In the example of Figure 1 1 1, the trend frequency has 
been set to daily. The trend analysis is then run and the raw data displayed as 
shown in Figure 1 12. Referring to Figure 113, various graphing options are pro- 
vided. In the illustrated example, the data is presented in the form of line graphs. 

Trend reports, aside from comparing one account to another over the iden- 
tical period, may also compare the same account over different periods. Hence, in 
the case of both financial reports and trend analyses, an important feature is that 
the date range of the report is arbitrary. Historical data for all past periods (or at 
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least a considerable number of past periods) is stored in the database, enabling 
reports to be run for any period of time, not just the current period. 

Human, Group and Organization Performance 

Having described for an order the course of events in the financial perfor- 
mance domain, the course of events in the personnel domain will now be 
described. 

By and large, present-day work activities are based on the model of an 8- 
hour work day, 40-hour work week. What is tracked quantitatively is time and 
attendance. Actual performance, by and large, is tracked qualitatively. Although 
such a model may have been adequate for the industrial revolution, it is inadequate 
and without basis for purposes of the information revolution. Instead, the present 
system allows performance to be quantitatively tracked. 

Referring to Figure 114, there is shown a human resource infrastructure for 
a virtual organization performance evaluation model. All company personnel are 
linked to a digital U HR backbone," including operational management (V.P.s, 
managers), engineering, strategic management (president), financial and legal per- 
sonnel (CPA, lawyer), and staff within various departments (customer service, 
shipping/receiving, technical, accounting, purchasing, etc.). In concept, the HR 
backbone could be any information conduit. In an exemplary embodiment, the HR 
backbone is realized by the same integrated, Web-enabled, client/server database 
as described heretofore. Various functional blocks manipulate data stored within 
the database and form a personnel module. 

Two functional blocks in particular from the basis for performance evalua- 
tion, a Measurement Factors block and a Score Keeper block. For each individual 
whose performance is to be tracked, a list of tasks performed by the individual is 
compiled, together with an estimate of what percentage of the individual's overall 
assignment each particular task constitutes. Using this information, the individual 
participates in the setting of realistic goals within various categories. These goals 
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are stored so as to readily accessible to the individual for frequent review. The 
goals in turn dictate measurement factors/parameters tracked by the "descriptive" 
Measurement Factors block. These factors/parameters form the answer to the 
question "What is the pertinent data within the database upon which to evaluate 
the performance of the individual?/' both individually and as a team player. Sug- 
gestions received from within the organization may influence the pertinent mea- ' 
surement factors/parameters. 

The question, "How should the data be viewed?" is answered by a group of 
"normative" functional blocks. These blocks generate outputs to the Score Keeper 
block, which measures the degree of success or failure with respect to each goal. 
The same outputs are input to a "presentation" block that serves to educate 
employees as to the effects of various normative performance measures on finan- 
cial performance and on factors affecting customer satisfaction, to help employees 
identify trends, etc. 

Customer feedback (both commendations and complaints) are preferably 
also be received by and input to the system. A firewall provides security for inter- 
nal data and allows limited access by customers to provide feedback. Customer 
feedback, although not strictly objective like the other factual measures of perfor- 
mance tracked by the database, can be an important indicator of performance. 

Referring to Figure 1 1 5, a more detailed view is shown of the kinds of data 
stored in the human resources portion of the database. With the exception of data 
relating to performance measurement factual review, the data represented in Fig- 
ure 1 1 5 is static or semi-static data that changes relatively infrequently or not at all. 
The top portion of the figure relates to candidate data, whereas the bottom portion 
of the figure relates to employee data. 

For candidates, data stored in the database includes personal data, previous 
employment data, and previous performance data. The data is obtained from the 
candidate and from other outside sources, and may also be made available to the 
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candidate, e.g., through the Web. During the hiring process, employment docu- 
ments are scanned (or input directly by the candidate during the application pro- 
cess) into the database. For employees, data stored in the database also includes 
personal data, employment data and performance data. In addition, for employees, 
data regarding achievements and special recognition is stored. 

Performance measurement factual review is dynamic in nature and may be 
performed in a manner illustrated in Figure 116. Depending on the organizational 
level, performance measurement is either financial-oriented or assignment ori- 
ented. For branches, divisions, subsidiary companies and their parent company, for 
example, performance measurement is financial-oriented and uses financial analy- 
sis algorithms. In particular, using the universal financial report generator 
described previously, any desired financial ratio may be tracked, as well as any 
arbitrary combination of account codes in order to discover relationships. Cash 
flow statements and budget analyses may also be generated. Based on this infor- 
mation financial performance goals may be set and contributing goals may be 
accurately derived. 

At the department, group and employee level, performance measurement is 
assignment oriented. 

Referring to Figure 116, evaluation of human performance is made possi- 
ble by collecting an assemblage of activity data to which analysis algorithms may 
be applied. This assemblage of activity data is referred to as Algorithm of Activity 
Data. For each different assignment (e.g, Quotes, MWSs, Customer Invoices, etc.), 
activity is tracked in three principal ways: quantity per period, dollar volume by 
period, and time between stages of completion (e.g., time from posting of quote to 
conversion to MWS). The relevant period is preferably user-selectable. In addi- 
tion, the responsible department and the upstream and downstream departments 
that affect and are affected by the assignment are identified (and refined, if neces- 
sary, as experience with the system is gained). RMAs affect all assignments and 
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are therefore tracked in relation to each assignment. For example, quotes made 
during a period may total one million dollars but may have ultimately resulted in 
half a million dollars of RMAs. 

The Algorithm of Activity Data serves as a foundation for human perfor- 
mance evaluation. Referring to Figure 1 17, for each individual employee to be 
evaluated, various metrics from the Algorithm of Activity Data are chosen and 
tracked for that employee, resulting in Employee Specific Task/Assignment Activ- 
ity Data. Different aspects (e.g, quantity, dollar volume, completion times) of an 
assignment (e.g, Quotes, MWSs, Customer Invoices) may be chosen as metric for 
evaluation for a particular employee. 

The Factual Performance Analysis Measurement process performs calcula- 
tion on the Employee Specific Task/Assignment Activity Data, for example calcu- 
lating time "deltas" between different stages of completion of an assignment. 
Resulting data is supplied to at least three destinations: a Measuring Algorithm, a 
Historical Data Comparison Algorithm, and an output display structure, indicated 
by dashed lines. The Measuring Algorithm compares actual performance to 
desired performance established by goals. Preferably, goals are set by employees 
in consultation with management. In an exemplary embodiment, the Measuring 
Algorithm compares actual performance to desired performance in three different 
categories: routine assignments (daily, on-going), scheduled tasks (not on-going) 
and special projects (typically short-lived). In addition, unique date-independent 
measurements may programmed, for example as alerts. For example, the user may 
program the Measuring Algorithm to alert the user whenever the time delta 
between creation of a quote and posting of the quote is seven days or greater. Var- 
ious priorities may be established in accordance with corresponding parameters. 
For example, a particular order may be marked as critical, causing an alert to be 
displayed if there is any slippage in schedule. 

The Historical Data Comparison Algorithm archives the daily output of the 
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Factual Performance Analysis Measurement and the Measuring Algorithm blocks 
and allows for comparison of performance data for different dates. 

Within the output display structure, a hierarchy of views is presented. A 
first view is a complete list, based on the Algorithm of Activity Data, of depart- 
ments and the tasks and projects for which they are responsible. From this com- 
plete list, the user may create the users own "short list" of departments for 
performance review. Different layers of management, for example, may have dif- 
ferent departments within their scope of review. 

To display performance data, the user selects a department, causing perfor- 
mance data to be displayed for the department as a whole. The user may further 
select a specific individual within that department, in which case a Dynamic Per- 
sonal Tracking view is displayed. The Dynamic Personal Tracking view displays 
all of the chosen metrics for the selected employee. From the Dynamic Personal 
Tracking view, the user may transition to a Factual Perfonnance Display. The Fac- 
tual Performance Display is a subset of the Dynamic Personal Tracking view and 
focuses on those metrics presently deemed by the user to be most important (e.g., 
metrics related to sales growth, metrics related to customer service, etc.) 

The Factual Performance Display highlights strengths and weaknesses of 
the employee and is linked, either automatically or manually, to static human 
resources "personal growth guides." Based on the Factual Performance Display, it 
may be evident, for example, that the employee in question needs training in a cer- 
tain area. In this manner, the system allows training efforts to be narrowly targeted 
where they will obtain greatest benefit. A career path may be charted for each 
employee that is calculated to maximize that employee's potential. 

Screen displays used for factual performance evaluation in accordance with 
an exemplary embodiment of the invention are shown in Figure 118, Figure 1 19 
and Figure 120, respectively. Selection of an employee is accomplished as illus- 
trated in Figure 118. Referring to Figure 1 19, performance results may be viewed 
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for a single period or multiple periods, with the period being user selectable (a day, 
a week, a month, a quarter, etc.). In the case of the single period display, perfor- 
mance results for various performance metrics in different categories and sub-cate- 
gories are displayed, for example: Productivity (A), including quantity per period 
(Al), dollar volume per period (A2) and percent profit per period (A3); Quality 

(B) , including timliness (Bl) and customer credit memos (B2); and Profitability 

(C) . In the case of the multi-period display, the same information is viewable for 
multiple periods but, because of display contraints, not all of the information at the 
same time. Rather the user selects the categories and sub-categories of interest for 
viewing at any particular time. For example, if sub-category A2 is selected, then 
dollar volume per period is displayed for all of the periods (e.g., six). 

Percolation — Automated Low-Level Decision-Making 

In order to automate a small-to-medium size business, relatively complex 

tasks must be automated so as to be accomplished with a few clicks of the mouse. 
The present system accomplishes such automation using a technique referred to 
herein as "percolation." Percolation involves automatically classifying records of a 
given type into multiple classifications for workflow processing. One or more 
users interact with the relational database system to take a prescribed action with 
respect to multiple records having a particular classification. The records of a 
given type are classified into multiple classifications based on "experiential" crite- 
ria having real-world business significance based on past business experience. A 
record may belong to a multiple categories. Records are sorted in accordance with 
a hierarchy of categories such that a record belonging to both a category higher in 
the hierarchy and a category lower in the hierarchy is sorted into a group of records 
belonging to the higher category. The relational database system does not allow 
users to take at least some actions other than the prescribed action with respect to 
the records. Users interact with the relational database system to change informa- 
tion within records, whereupon the records are automatically reclassified. 
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Percolation may be applied to any business function, but has found to be 
particularly effective as applied to PRIS (purchasing, shipping, receiving, installa- 
tion and assembly), vendor invoice verification, customer collections and process- 
ing of returns. Percolation may be single-level or multi-level. 

Percolation as applied to vendor invoice verification has been described 
previously. As was previously observed, the hierarchy of classifications is impor- 
tant in order to obtain the desired results. To take advantage of dynamic workflow, 
however, it is desirable that a user having the requisite authority be provided with 
the ability to change hierarchies (specify a new order of classification), both within 
a single level and on multiple levels. There results a very powerful ability to "slice 
and dice" data records stored within the database, which in turn provides for 
dynamic response to outside influences. 

Referring to Figure 150, percolation as it applies to purchasing will be 
described. Sales orders resulting from quotes undergo a first level of percolation to 
identify sales orders on credit hold, sales orders exceeding credit limits, sales 
orders with customer invoices 60 days or more past due, sales orders with freight 
problems, sales orders with installation, sales orders with installation and/or ship- 
ping problems, sales orders with a ship group, sales orders with partial ship, etc. 
As a result of this first-level percolation, certain orders may be placed on hold, or 
corrections may be made to the order as required. 

There follows a second-level percolation at the item level preparatory to 
placing vendor orders. Items undergo percolation to identify items with higher 
sales cost than sales price, items with higher purchasing cost that sales cost, items 
on back order with groups (install/ship), rush items, items with back order received 
in a "no partial" sales order, items with promotion or rebate, etc. In accordance 
with one aspect of the invention, such percolation in effect identifies "critical path" 
items for fulfilling an order, items that will take the longest to fill based on avail- 
ablity, installation instructions, shipping instructions, etc. 
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Corrections may be made and reclassification performed until such point as 
the user is ready to order. The user then prepares a purchase order request, either 
using a default vendor determined at the time the order was placed (lowest cost 
vendor) or selecting a different vendor. The vendor order may then be placed by 
posting via the Web, or the vendor order may be posted on the Web for bid. In the 
latter instance, bid results are received via the Web, and the vendor order is then 
placed based on the bid results. The order is filled by the vendor and shipped to the 
reseller or drop shipped to the customer. 

Note that purchasing may or may not involve vendor selection. At the time 
a quote is created, a default vendor is selected based on lowest advertised price. 
Order information may, if desired, be automatically transmitted to the default ven- 
dor. In fact, N-tier order information may be automatically transmitted to multiple 
corresponding vendors as described more fully hereafter in relation to supply chain 
management. 

Referring to Figure 151, percolation as it applies to receiving will be 
described. Sales orders for which vendor orders have been place and that need to 
be received undergo a first level of percolation to identify receiving sales orders to 
be refused or cancelled (because of RMA, for example), COD sales orders, express 
delivery, sales orders marked for special tracking (e.g., call upon receipt), replace- 
ment sales orders, no partial or restricted partial sales orders with only one item, 
sales orders expecting back order items, sales orders with installation, sales orders 
without installation, inventory sales orders, supply sales orders, RMA returns 
expected from customer, RMA returns expected from vendor, RMA returns 
requiring install/de-install, etc. 

There follows a second-level percolation at the item level preparatory to 
actually receiving items. Items undergo percolation to identify items cancelled, 
items to be refused, items with COD, items with express delivery, items for 
replacement orders, items marked back order, items in an auto-tracked sales order, 
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items holding up installation, items holding up ship group, RMA items needing de- 
install, etc. Corrections may be made and reclassification performed until such 
point as the user is ready to receive. The user then starts the receiving process and, 
optionally, receiving status is posted via the Web or via email to selected custom- 
ers and/or vendors. 

Shipping percolation is in large part analogous to receiving percolation, 
previously described, and is illustrated in Figure 152. 

Installation percolation is illustrated in Figure 153. Installation percolation 
may be single-level, identifying sales orders with a large quantity of installation, 
sales orders ready for software network integration, sales orders ready for assem- 
bling, sales orders missing one last item, sales orders with a defective component 
for RMA processing, sales orders with RMA waiting for vendor shipment, sales 
orders with RMA needing de-installation, sales orders with RMA needing re- 
installation, sales orders with RMA for warranty repair (off-site, on-site), sales 
orders with RMA for out of warranty repair, etc. 

Supply Chain Integration/Management 

The present software program provides for Web access by various business 

partners to all of the information relevant to the business. The software may there- 
fore be described as Web-enabled Enterprise Resource Planning (WERP) soft- 
ware. The present WERP software allows for an unprecedented degree of supply 
chain integration/management. Referring to Figure 154, a left-hand side of the fig- 
ure illustrates a sell/demand chain, and a right-hand side of the figure illustrates a 
supply/assembly chain. User demand information is gathered by a user following a 
URL link from a customer Web site. The link accesses the present WERP soft- 
ware. Using the software, the user creates a quote. Assuming the ordered item is 
not discontinued, the quote may be converted into an order. The item may be sold 
complete with no component assembly required, or may be sold with component 
assembly required. In the former instance, the order is posted to purchasing, and 
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the item is ordered, e.g., by communicating order information to a vendor Web site 
and a manufacturer Web site. In the latter instance (component assembly is 
required), a component file is accessed to retrieve a unique set of components for a 
specific item SKU. Given the order quantity, a total component requirement is 
determined. Within PRIS, component grouping is performed, e.g, such that multi- 
ple "child" MWSs each contain (in bill-of-material fashion) all of the components 
required to assembly a single one of the ordered items, and a "parent" MWS of the 
children MWSs contains the corresponding number of complete items. The com- 
ponents are ordered by, as in the previous instance, communicating order informa- 
tion to a vendor Web site and a manufacturer Web site. 

Note that, if an item is discontinued or not available (i.e., backordered), if 
the items component parts are still available, the item may still be sold, the compo- 
nent parts ordered and assembled, and the item shipped. Equivalent components 
may be substituted where necessary or convenient. Also, order information may be 
conveyed to a hierarchy of suppliers. In the case of a computer, for example, the 
vendor may be Ingram and the manufacturer may be Compaq. Compaq's suppliers 
may include makers of microprocessors, memories, disk drives, etc., whose suppli- 
ers may include in turn wafer manufacturers, platter companies, plastic companies, 
etc. 

One key to the type of supply chain management described is breaking 
down items into multiple "tiers," each successive tier including component parts 
for items of a previous tier, and creating a record for each component part. Sup- 
plier relationships from one tier to the next may be identified based on information 
that is automatically updated on a frequent or substantially continuous basis. Per- 
colation of the type previously described may then be performed on component 
parts, with classification being performed on the basis of availability within multi- 
ple tiers. Availability information within multiple tiers may be obtained via the 
Web. If customer specified installation and/or shipping instructions are likely to 
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cause substantial delay in filling an order given availability information, the cus- 
tomer may be contacted to see if the customer desires to change instructions in 
order to minimize delay. In the case of channel assembly, when component parts 
are received, they are assembled into items for shipment to the customer. 

There results a virtual inventory system with no backorders in which the 
order cycle time for the entire supply chain is compressed to that of a single order 
(single stage of a typical supply chain). 

Web Universal Business Engagement Rules (WUBER) 

Various customer-specific customizations of the behavior of the present 

WERP software have been described. Information representing desired customiza- 
tions for a particular customer are stored in a customer file of that customer. Dur- 
ing operation of the software, whenever customizable operations are performed, 
the software checks the customer file to determine how to proceed. 

Such customization may be extended to embrace virtually all of the "busi- 
ness engagement rules," both general and industry-specific, commonly negotiated 
between business partners. Such business rules serve as an electronic template for 
specifying a customized business relationship. By providing Web access to a com- 
prehensive ("universal") set of relevant business engagement rules, the creation 
and management of information-age business relationships is greatly simplified, 
The feature of providing Web access to a comprehensive set of relevant business 
engagement rules is referred to herein as WUBER ("Web Univeral Business 
Engagement Rules"). 

In a preferred embodiment, WUBER not only provides for the specifica- 
tion of business engagement rules, WUBER also provides for the enforcement of 
the business engagement rules during the course of business operations. For exam- 
ple, during the course of a business relationship, the customer may decide that all 
shipments are to be made via a specific carrier. Once that carrier has been specified 
for that customer within WUBER, the software will not permit shipments to be 
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made via a different carrier. 

The extent to which a customer may freely change that customer's business 
engagement rules may vary by customer. For some WUBER fields, all customer's 
may freely select any available menu choice. For other fields, bounds may be set 
within which the field may be changed. These bounds may vary from customer to 
customer. Hence, whereas an acceptable return period for one customer may be up 
to 90 days, an acceptable return period for another customer may be up to 180 
days, for example. 

New business engagement rules may be easily added to WUBER. Pres- 
ently, as new business engagement rules are added, enforcement code must be 
manually written and added to the software program. In the future, such enforce- 
ment code may be automatically generated. 

A specific example of a WUBER electronic template in table form is 
shown in Figure 155. Within the header row of the table are listed various custom- 
izable program tasks. Each column of the table lists various options pertaining to a 
particular task. Various fields of the template will be briefly described. 

Various options in the Price Update column govern how products are 
priced and display for a particular customer. If an Activate flag is set, the options 
selected within the column will be enforced during operations of the software. If 
the Activate flag is not set, program defaults will be applied instead. Pricing may 
be fixed price or cost plus. The frequency with which prices are updated is select- 
able, e.g., daily, weekly, monthly. If a customer has obtained a quote but not yet 
placed an order, for example, the customer may want the quote price to not change 
(even if in the customer's favor) for a specified period of time. Furthermore, a 
price minimum update amount may be specified; for example, price changes less 
than a dollor (or, say, less than 1% of the previous price) might be ignored. Vari- 
ous other options relate to the manner in which products are displayed, for exam- 
ple all products, new products, discount products, products of a specific 
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manufacturer, etc. A Personal Product List (PPL) is a user-specific list of fre- 
quently-purchased products. A Product ID (PID) is a collection of products (usu- 
ally related) saved under a single identifier. 

In the Quotes column, the customer may specify which system users may 
create quotes, which may save/retrieve quotes, which may modify quotes, and 
which may submit quotes. The customer may further specify various limits, e.g., a 
per-quote dollar limit, a per-day quantity limit, a limit on the number of quotes 
made per day, etc. Similar options are provided in relation to Orders and RMAs. 
Note, however, that an important option in relation to RMAs is automatic RMA 
approval. 

In the Service & Repair column, various options may be specified, includ- 
ing service contract length and service response time, whether service to occur on- 
site or off-site, various service charges, etc. In the Shipping column, various deliv- 
ery options are specified. In the Tracking column, various options are specified 
regarding how customer order information is to be tracked, e.g., whether tracking 
by serial number is desired, as well as various tracking thresholds by dollar 
amount, how recent the transaction is, quantity, etc. 

In the Invoice column, various options relating to invoice delivery are pre- 
sented. In addition, the customer may specify a billing frequency and whether 
credits are to be applied to invoices, whether replacement invoices are to be issued, 
etc. In the Credit Memo column, the customer may specify whether credit memos 
are to be issued to the customer (external) or whether an internal credit is to be 
issued, etc. 

In the Payment column, various payment options are specified, including 
whether the ability to retrieve payment information is desired, credit card limits 
(credit card purchase dollar limit and frequency limit), check information, and 
EFT (Electronic Funds Transfer) limits. 

In the Security column, various security options are specified, including for 
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example, encryption, SET (Secure Electronic Transactions), security certificate, 
VPN (virtual private network), etc. Security may be handled by the customer on its 
own behalf or may be handled by the vendor. The present WERP software may in 
some instances be installed within the customer's firewall such that it becomes in 
essence part of the company. 

The Access Group column is used to specify the access rights of different 
users. In the case of viewing quotes, for example, access may range from access 
only to one's own quotes (individual access), access to one's own quotes and those 
of user's whom one supervises (supervisory access), or universal access (in the 
case of a high-ranking executive, for example). 

The Business Activities column is used by the customer to request that cer- 
tain information about its business activities be tracked and made accessible. Such 
information may include, for example, the busiest order period (week, month) the 
slowest order period (week, month), etc. 

The electronic template of Figure 1 55 is for the customer side of a business 
relationship. A corresponding template may also be provided for the vendor side of 
a business relationship. That is, from the point of view of a reseller, the template of 
Figure 155 expresses demands of the reseller's customers on the reseller. The tem- 
plate of Figure 156 expresses the demands of the reseller on the reseller's vendors. 

A further example of WUBER is shown in Figure 160, showing a customer 
file screen display. Within the right-hand portion of the display, the customer is 
able to, via the Web, set customer-specific criteria for automatic RMA approval. 

Virtual Intelligent Guide (VIG) 

As should be apparent from the foregoing description, the present WERP 

software is designed to minimize the impact of personnel changes. To achieve this 

goal, the WERP software incorporates a Virtual Intelligent Guide (VIG). The VIG: 

1) defines a task path for accomplishing each functional task by interacting with 

the system; and 2) captures and applies employee knowledge to refine each task 
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path and disallow errors. The result is to enable relatively unskilled personnel to 
quickly become proficient at performing complex functional tasks in a simple 
manner using the software. An example of VIG was described previously in rela- 
tion to accounts payable. The same model may be applied to accounts receivable, 
RMAs, sales, PRIS, etc. 

Tracking Prospective Customers and Vendors 

Customer and vendor files may be provided not only for existing customers 

and vendors but also for prospective customers and vendors. In the case of ven- 
dors, prospective vendor files provide a mechanism for capturing the knowledge of 
buyers in purchasing and of minimizing the impact of personnel changes. In the 
case of customers, prospective customer files facilitate sales force automation as 
will be presently described. 

Sales Force Automation 

During sales calls, a salesman will often be asked various question about 

particulars of various business transactions. If the salesman happens to know the 

answer, the salesman can answer immediately. More typically, the salesman 

doesn't know the answer and is forced to reply "I'll have to get back to you on 

that." "Getting back to you" will usually take days and may even take weeks, or 

may simply not happen at all. Current sales force automation software does little to 

address this situation. 

The present WERP software provides the ultimate sales force automation 

tool. Instead of "Til have to bet back to you on that," the salesman can instead say 

"Let's check on that." The salesman may then immediately use the Web to access 

the information needed to answer the customer's question. Web access may be 

through a desktop or laptop computer, either wired or unwired, or may be wireless 

through a handheld or palmtop computer. Alternatively, connection to the Web 

may be made prior to a sales call to download for a particular customer — all of the 

records, the most recent records, or some other subset of particular interest. 
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In addition to the foregoing functionality, various features of existing sales 
force automation tools may be added to the present WERP software, including 
such features as contact management (contact profile, contact history), account 
management (account information, outstanding and historical activities, order 
entry, order history, lead tracking, sales cycle analysis), sales force management 
(expense reporting, territory assignment, activity reporting, special events track- 
ing), time management (calendar, single and multi-user scheduling, to-do lists, 
ticklers, notes, timestamps), telemarketing (call list assembly, call recording, call 
planning, call reporting), customer service (request assignment, tracking and 
reporting, order status and tracking), etc. All of these functions can be performed 
"on-the-fly," in real-time with up-to-the-minute information. This real-time opera- 
tion is made possible because the underlying data is the same item sold/item detail 
data used throughout the system, simply viewed from an SFA perspective. 

Figure 157 is a block diagram of a client/server business automation sys- 
tem in which a common database supports both end-to-end business process auto- 
mation and sales force automation. 

Referring to Figure 158, the sales force automation capabilities of the sys- 
tem of Figure 157 are represented in greater detail. A sales force automation mod- 
ule combines known sales force automation functions with additional functions 
made possible only by the end-to-end business process knowledge base stored in 
the single database described previously. 

Known sales force automation functions include, for example, activity log- 
ging (actual time and data of daily activites by customer), intelligent notes (sort- 
able and editable), and triggers (reminders) for follow-up calls, major 
opportunities, etc. The functions are supported by a summary display (drawn from 
the customer file) used to display contact information for customers by department 
and title. Various other functions may also be provided. 

An expense reporting function is also provided. Unlike conventional sales 
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force automation tools, however, expense information is combined with compen- 
sation information stored in the database in order to gain a complete picture of the 
profitability of a saleman. Based on profitability, a rewards structure may adjust 
the compensation of the salesman and provide performance feedback to the sales- 
man through the sales force automation module. 

Forecasting information may also be displayed to the salesman through the 
sales force automation module. Because the database stores complete historical 
transaction information, a sales forecast can be readily compiled based on the his- 
torical base. Other types of forecasts can also be compiled. For example, market 
projection information may be entered into the database (downloaded or entered 
manually), and based on this information, a forecast can be compiled. A forecast 
can also be compiled based not only on current customers but based on prospective 
customers. Such a forecast provides additional motivation for a salesman to con- 
vert prospective customers into actual customers. 

Information from WUBER may also be displayed to the salesman through 
the sales force automation module. When a new salesman succeeds a departing 
salesman, the new salesman, by consulting WUBER, can readily learn the estab- 
lished business engagement rules for a particular customer. 

Information from the human performance module may also be displayed to 
the salesman in the form of an activity summary display. In an exemplary embodi- 
ment, activities in various categories (columns) are quantified (rows) in dollars 
where applicable (for both sales and purchase orders), in quantity where applicable 
and in duration where applicable. For example, dollars sales, dollars purchase 
orders, and unit volume (quantity) are displayed for the previous year, the present 
year, and for the previous month, as well as for the peak month (max.) and the low 
month (min.). In other categories, e.g., ship-to-date and payment history, an aver- 
age time in days is displayed, between the time an order is placed and shipped and 
the time an invoice is sent and paid, respectively. 

An example of a screen display for Sales Force Automation is shown in 
Figure 161. 
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Purchase Requisition Budget Forecast 

Orders, represented by MWSs, may be for resale or for internal use. A field 

within the MSW record distinguishes the type of MWS, including whether it is for 
internal use. Just as historical analysis and forecasting may be applied to customer 
sales, these same techniques may be applied to internal sales. The cycles of pinch/ 
spend that often aflict corporate departments may therefore be avoided. Manage- 
rial personnel are able to determine easily in real time how much of a budgeted 
amount has been spent and how much remains to be spent. 

Comparison With Known Workflow Systems 

In contrast with known workflow systems, the present system, sometimes 
referred to hereinafter as the ICE™ (Internet Commerce Equalizer) system, repre- 
sents a purpose-built application suite where all applications are both physically 
implemented and logically rational source or target applications in a Dynamic 
Workflow™ Environment 

The ICE system may be described as a broad-spectrum suite of Internet- 
optimized business applications, that are designed and built to permit the imple- 
mentation and execution of workflows without the mandatory parameter setting, 
software switch setting, customization and workflow preparation common to all 
other workflow environments. This is made possible by several, simultaneous 
development and runtime environment characteristics and by several carefully 
considered simultaneous application design and development practices. 

To appreciate the difference between the ICE system and conventional 
workflow systems, the background of conventional workflow systems will be 
briefly described. 

Arguably the origins of workflow are as ancient as the origins of industry. 
In modern industry, workflow has taken the form (under different names) of the 
assembly lines of Henry Ford, or as the doctrines of time and motion as formalized 
by industrial theorists like Taylor and Gilbraith. 
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Very recently, (the 1980s) workflow has appeared in computing and office 
automation in the form of task-based menus and wizards. Most recently, (the mid- 
1990s) workflows have taken the form of environments that tie ordinary business 
applications together into larger, structured super-applications that consist of 
applications tied together in a workflow definition environment driven by work- 
flow "engines " 

These environments have the capability of performing state-transition or 
branching logic in contrast to the more mundane task-based menus. And unlike 
wizards which are normally used for intelligent installation procedures, workflows 
are usually used to support the structured execution of routine business applica- 
tions. 

Examples of such environments could include SAP's workflow operating 
in the Dr. Schier™ graphical workflow environment or Baan's Dynamic Enter- 
prise Modeling running in the COSA™ environment. And, these environments 
have one common heritage with workflow of the past. Notwithstanding words like 
"dynamic" in their names, these environments are inherently static. 

Static is used to mean that once a workflow has been built and imple- 
mented in any of these workflow environments, it stands as a defined super-appli- 
cation. To execute a workflow in any of today's existing workflow environments 
that has not been previously defined, prepared, and implemented is not possible. A 
user attempting to do so would find himself in the same position as a factory 
worker who attempted to execute an assembly procedure off the assembly line. He 
would find himself without resources or the means to execute any procedure for 
which a physical infrastructure had not yet been created. 

The ICE system has a true dynamic workflow environment. This means 
that the users of the ICE system can go places with the application even when the 
metaphorical steel rails of an assembly line have not yet been built there. 

In order for this to happen, the ICE environment must be fundamentally 
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different from competing pre-defined, structured workflow environments. The 
basis of this dynamic flexibility and the goal of all recent design efforts is the 
enabling of all ICE applications as potential sources or targets in a workflow. 

This potential must be inherent, and not the result of extensive preparation, 
switch setting, or parameter setting of older-generation applications. It does not 
even matter if this preparation is largely automated in a separate (static) definition 
and development environment, because such relative ease of building workflow 
scaffolding is qualitatively different than not requiring scaffolding for workflow 
mobility in the first place. 

Real-world business users of older-generation enterprise applications have 
made comments like, "it's like taking off handcuffs," to navigate and solve busi- 
ness problems in the ICE system. Dynamic Workflow means that the user is not 
bound to one pre-defined way of doing a business procedure or of solving a prob- 
lem. 

Of course, the ICE system can enforce business procedures (in fact most 
routine business procedures in the ICE system are completely automated) and of 
course the ICE system is capable of enforcing GAAP and APICS standards in 
accounting and manufacturing. But wherever possible, the ICE system gives the 
user a choice even as it automates routine procedures. And when it comes to 
exception handling, the Dynamic Workflow environment in the ICE system saves 
significant time and effort. 

In ordinary ERP and business systems, sequences of applications known as 
workflows are built up using specialized development environments. As with any 
other application, workflow or subsystem that is built up from either lines of code 
or from higher level components or applications, nothing exists that has not been 
previously defined and built. 

In other words, to execute a particular workflow, someone must first 
implement it. The implementation system must follow strict rules and in many 
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cases perform complex re-configurations of the workflow applications so that they 
are properly enabled as "source" or "target" applications. The workflow environ- 
ment starts out either as a template of other pre-existing workflows, or simply as a 
blank slate on which to build the workflows that are to eventually be executed. 

In the ICE system, by contrast, it is possible to navigate a comprehensive 
"web" of applications in any way needed by the user, with each and every applica- 
tion already a potential source or target application to every member of the naviga- 
tion web. 

A unique feature of the ICE system is its capability to support Dynamic 
Workflow. Dynamic Workflow may be described as follows: 

• Conventional workflow starts with a blank slate and then builds up 
the workflow from individual applications or components. Even 
when workflow templates are used those templates simply specify 
which components are added by default to the blank slate. 

• In conventional workflow systems, applications must be carefully con- 
ditioned, parameterized, and otherwise programmed to work together 
in a specific workflow, because they must often pass messages, passed 
parameters, or transactions between them. Those transactions must be 
data-type and business-rule-logic compatible. 

• The applications that comprise a workflow will rarely work outside of 
the specific work flows they were designed for. This is because in con- 
ventional application systems the applications work more or less inde- 
pendently and are typically constructed around one or more specific 
(and independent) data files. 

• This means that work flows must be constructed just like applications. 
Nothing is executable unless it has already been defined and imple- 
mented. The only difference is that applications are built up from rou- 
tines and workflows are built up from applications. Workflows are 
simply hyper-applications that are built from components at a coarser 
level of granularity and a higher level of abstraction than the individual 
applications that make up the workflows. 

• Even the most sophisticated and flexible of the existing workflow sys- 
tems require active developer, designer, analyst and system-support 
intervention before the workflow can be implemented. 



Conventional workflow works as a "start with nothing and build" 
method. No application-to-application pathway exists unless and until 
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it is actively implemented. 

The ICE system has a number of architectural characteristics that when 
combined, produce a unique Dynamic Workflow execution environment: 

• It is a characteristic of the ICE architecture that all applications are 
object-based methods that interface with a unified, synchronous, 
"solid-state" database. 

• These methods are written in such a way that most of them can be 
safely invoked in any order. Because these methods are actually only 
different logical views of the same "solid-state" database, any changes 
made by one method to the "solid-state" database, are simultaneously, 
instantaneously, and synchronously virtually "posted" to all other 
methods, in the ICE system. 

• It should be noted that this posting is strictly virtual. No physical 
parameter passing is done and none is required, because there is only 
one database operating under strict rules of commit control. All data- 
base updates are accomplished synchronously, and under the protec- 
tion of internal database commit control such that any data update is 
instantaneously and simultaneously propagated through any view that 
sees that data. 

• In contrast to workflow systems where business objects are placed on a 
blank slate, and where no workflow exists that has not been previously 
defined, the ICE system is a web of business functions (methods). 
Potential connectivity and application-to-application workflow are uni- 
versally present. 

• This permits a "start with everything and set guidelines" workflow 
model. 

• Normally, in the routine user interaction with the ICE system, routine, 
pre-defined business workflows are followed, and these are docu- 
mented and programmed into the system as user guidelines, task-based 
menus, wizards, or procedures. Workflows may also be defined with 
state-transition intelligence, such that a particular data entry value will 
result in changing the next application along the application path. 

• At end-user security levels, these procedures can be defined so that any 
change from a normal business procedure requires supervisor approval. 
User roles, rights and authorities can be comprehensively managed. 

• However, if an exception condition arises, the user of the system has 
the option of invoking whatever necessary relevant application is 
required, with the assurance that data integrity, data consistency, and in 
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most cases, business rules will not be violated. 

Occasionally, management or supervisors will want to change busi- 
ness rules on purpose, and this can be done at a high enough level of 
supervisory system authority. 

Furthermore, all workflows in the system and the applications that 
comprise those workflows are structured in such a way that the work- 
flows can readily be reversed at any time. An example would be when 
a sales situation turns into an RMA. In such a situation, the same 
workflow can be changed into a reverse workflow at any stage by sim- 
ply reversing navigation. 

It should be noted, that whenever necessary, rational business rules can 
be overlaid on top of this "universal navigation Web" as would be the 
case if the invocation of a method results of posting the general ledger. 

In such a case, business rules dictate that the original posting general 
ledger must remain intact, and the corresponding opposite entry must 
be made. Even when such exception conditions are defined, universal 
navigation of the system is still possible if the user has a high enough 
level of authority. 

By creating a workflow environment where nearly any business 
method invocation sequence can be followed without violating system 
integrity, the ICE system has achieved a new level of system flexibility 
and the ability to respond to business contingencies. 

Even in the most flexible conventional workflow systems, situations 
arise where new methods need to be inserted into a workflow 
sequence, or other methods need to be removed, or an alternate method 
substituted for the original method. In a conventional workflow sys- 
tem, the new procedure must be defined, the applications properly pre- 
pared, through the setting of parameters and switches, and then the 
workflow must be tested. 

In such a situation, both application logic and database changes can 
have a negative "ripple effect" throughout the system often requiring 
extensive impact analyses. 

Obviously, this process is time-consuming, and is not practical for 
response in a contingency or exception situation. In the ICE system 
predefined workflows are set out as guidelines for normal business pro- 
cedures such as order entry. At the same time, the user is able to over- 
ride these guidelines whenever necessary. It means that the system can 
respond dynamically to changing business conditions. 

While it should be emphasized that the system does not create applica- 
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tion functionality or business methods were none existed previously, it 
should also be emphasized that the system is capable of dynamically 
adapting business workflows to ever-changing conditions. This allows 
the ICE system to respond dynamically to business impacts. 

• Even where new methods are required to support previously undefined 
and non-implemented business method functions, the developer work- 
load to create such new functions is greatly reduced in the ICE archi- 
tecture because of its natural immunity to ripple effect. A new business 
method has zero impact on all existing business or future new business 
methods, and any additions to the database have zero impact on all 
existing or future new business methods.. 

• Even in the rare instance of a change to the database, automated data 
type declaration and synchronization in the ICE development environ- 
ment allows the rapid, comprehensive and automated update of all the 
business methods in the system. This is an extremely powerful feature, 
and a necessary one because in order to be intrinsically workflow- 
enabled, all ICE applications must conform to the same data integrity 
and consistency rules. 

• In practice much of the work of creating workflows in standard work- 
flow environments consists of analyzing and controlling ripple effect, 
achieving project scope control, and conditioning the existing applica- 
tions to work in the workflows that the designer wishes to implement. 
The ICE system eliminates these traditional bottlenecks to workflow 
development. 

The foregoing discussion has focussed on the background, rationale and 
benefits of Dynamic Workflow. The following discussion will focus on keys to 
Dynamic Workflow in the ICE sytem. 

• Eliminate the need to pass physical transactions or parameters 
between applications 

An important purpose is served by eliminating the requirement to pass 
physical transactions or parameters between applications. Much of the condition- 
ing and preparation of conventional workflow systems involves detailed data type 
checking and transaction matching from a source object to a target object. This is 
true whether the source object is a "pure" object or a hybrid object consisting of a 
more conventional database table and corresponding application. 

If all the applications in an application system are actually methods that act 
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on a unified "solid-state" database, and if all data type checking is done centrally, 
then one major source of potential application incompatibility is eliminated. This 
is exactly what is done in the ICE system. The ICE sytem is developed using a 
RAD environment (e.g., 4D from ACI, Inc.) that is capable of performing auto- 
mated, centralized data type checking and declaration. 

In fact, in the ICE system, data or parameters cannot be passed to any ICE 
application because once any data in the ICE system are updated, they are already 
in any and every method or view in the system. While this architecture could con- 
ceivably create currency problems and scalability limits in very large implementa- 
tions, presently, no single ICE instance is designed to support more than a hundred 
or so users. Thus, ICE can operate on a "solid-state" instance of persistent data. 

In this environment, data integrity rules are enforced by conventional 
RDBMS mechanisms. In fact, the ICE data model can be deployed as an Oracle 
database for example. Data consistency cannot be violated either because of all 
ICE applications share identical data consistency rules. Business rules are guided 
(not enforced) by a combination of application logic and workflow. 

ICE can be and is coded to enforce certain business rules without excep- 
tion. These would include things like double entry bookkeeping transactions. In 
all other cases however, the user with a high enough level of authority can invoke 
applications in what ever order suits the business case. 

• ICE applications are coded to "open navigation Web" standards. 

Every ICE application is written as if it could be invoked by any other 
application in the ICE system, and contains the navigation infrastructure and user 
enabling to support the invocation of any other application in the ICE system. 
With very rare exceptions, which are only made to conform to certain accounting 
or business restrictions, this is the actual case. 

For the purpose of facilitating the execution of routine business processes, 
task-based, conventional workflow, and automated procedures or agents can be 
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used. The big difference comes in when it becomes necessary to override an estab- 
lished procedure, or possibly even create, on-the-fly as it were, new procedures or 
exception-handling workflows. 

One metaphor that describes the ICE system workflow in contrast to con- 
ventional workflow is that conventional workflow presents the implementation 
staff with a blank slate on which all workflow constructs must be implemented 
before they can be used. The ICE system presents the users with an open white 
board of potential navigation paths that are typically defined by navigation guide- 
lines. 

Regardless of which ICE application a user happens to be in, a direct navi- 
gation path exists to any other ICE application. When the user gets there, the user 
can almost always perform meaningful create, read, update, or delete operations on 
the data that they see through the new "window" that they have chosen. 

Furthermore, each ICE application is written at a much broader level of 
granularity than the typical application in a conventional system. Each view in the 
ICE system encompasses what would normally be two or three levels of drill down 
in a conventional system. 

Even the "fast path" user in a conventional system typically cannot make 
any changes to the data that they access through the manually invoked applica- 
tions, without potentially violating one or more business rules. In any case, the 
user of a conventional system is looking at data that were designed to be stored 
either as unit records or as the rows of data in a relational database designed to be 
displayed on one 80 column by 24 line screen. 

This is true even in systems that have been retrofitted with modern graphi- 
cal user interfaces. In such systems, the graphical user interface is an aesthetically 
pleasing overlay on top of applications and data definitions that were designed to 
completely different standards. 

The following table first lists in bold some of the primary architectural 
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characteristics that distinguish the ICE system from conventional workflow sys- 
tems. The rest of the table lists some of the consequences and spinoffs of this 
architecture. 
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Fundamental conven- 
tional workflow archi- 
tectural charactistics 
are in bold 


Fundamental ice im 
architectural character- 
istics are in bold 


Fundamental benefits ot 
ICE™ are in bold 


Fixed, static binding naviga- 
tion 


upen Navigation 


tnjoy the flexibility of inter- 
net browser-style navigation 


individual applications pri- 
marily maintain individual 
tables, or as in the case of 
"unified database" products, 
separate data areas 


ah applications are actually 

ohiect*hA«*H mpthnrl q that 

view the same synchronous 
database 


no data type mismatches or 

prmrc ara nrtccihla moc_ 
ciniio aits jjuo9iuic, iiico~ 

sages, parameters and trans- 
actions are passed virtually, 
not physically eliminating 
transaction errors 


Multiple independent data 
tables typically supported by 
multiple relational database 
instances 


une logically "solid-state," 
synchronous database 


one update by one user 
using one business method 
simultaneously and instanta- 
neously "posts" that update 
across all users and all busi- 
ness methods 


^-commerce and internet 
enabling typically a retrofit or 
add-on 


t -commerce and internet 
architecture is intrinsic to the 
ICE™ (Internet Commerce 
cnaDier/ arc n (lecture 


Both user navigation and 
inter-system communication 
are fully Internet enabled 


Applications must be retrofit- 
ted and customized to work 
in the workflow environment 
because they were originally 
written to be either stand- 
alone or conventional task- 
based menu driven applica- 
tions 


ice 1 " applications (business 
methods) are designed, 
architected and written spe- 
cifically for the workflow 
environment. Every busi- 
ness method is a potential 
source and/or target method 
to every other method. 


All business processes are 
reversible, flexible and exten- 
sible. The user has the func- 
tional equivalent of a 
browser "back button," as 
well as a routine workflow 
"forward button." The poten- 
tial navigation web Is a 3- 
dimensional geodesic of 
business methods 


Applications tend to be frag- 
mentary. In order to see all 
relevant data, several layers 
of drill down are provided 


Applications are written at a 
much broader level of granu- 
larity. Although underlying 
synchronous data is stored 
internally as 3NF relational 
data (no repeating groups, 
elements or foreign key 
dependencies), users can 
see (and manipulate) at least 
2 and usually more "drill- 
down" levels at once. 


Applications have a central 
function with muttmle over* 
lapping functions or data dis- 
play. It becomes 
immediately apparent to a 
user where they might need 
to move to place the data 
they want to primarily manip- 
ulate in the center of their 
chosen "data window." Fur- 
thermore, that movement is 
always possible. 


secondary characteristics 
follow: 


heatures: 


benefits: 


start with notning and then 
implement business functions 
as necessary 


start with open "go anywhere" 
navigation and define business 
process guidelines as neces- 
sary 


Users spend time on business 
process definitions, not on 
implementation mechanics 



WO 99/33016 



110 



PCT/US98/27496 



business process and best 
business practice templates 
contain applications lists, state 
transition rules and extensive 
application configuration 
switch, parameter, and data 
compatibility information 


business process and best 
business practice templates 
contain business method navi- 
gation guidelines and state 
transition rules only 


Much less chance tor errors. 
Much greater flexibility of navi- 
gation and execution if the user 
needs to go beyond the bound- 
aries of the predefined workflow 


Just because an application 
works in workflow "A" does not 
necessarily mean it will work in 
workflow "B" 


All applications are actually log- 
ical methods that view the 
same synchronous database 
and are compatible 


Data cannot get out ot synchro- 
nization. The results of busi- 
ness actions can be seen right 
away. 


Applications must "know" they 
are part of a workflow and won't 
work unless properly prepared 


Applications dont "know" or 
"care" if they are part of a work- 
flow or not 


Skipping a step, navigating to 
an alternate step or viewing 
results won't corrupt the work- 
flow 


workflows are logical and phys- 
ical super-applications made up 
of a number of sub-applications 


Workflows can act as it they 
were super-applications but 
workflow architecture is logical 
only 


Kipple effect is eliminated, 
implementation time is greatly 
reduced, users can concentrate 
on business solutions, not 
implementation mechanics 


Adding or removing an applica- 
tion from a workflow has a sig- 
nificant impact on the workflow 
and on the applications the 
workflow contains 


Adding or removing an applica- 
tion changes the logical out- 
come of a workflow but has no 
effect on the other appQcations 
in that workflow 




implementing a workflow 
requires development and test- 
ing 


implementing a workflow 
requires a rational business 
proposition 




Exception handling workflows 
must be anticipated or their 
need encountered and then 
they must be developed before 
they can be implemented 


Exception handling conditions 
can occur, require the ad hoc 
execution of a previously unex- 
ecuted workflow and optionally 
be formally defined 




Conventional ERP and other 
business applications must 
support physical message and 
parameter passing 


ICE™ applications are meth- 
ods that view the same, syn- 
chronous database. Physical 
transactions and parameters 
are not passed. 


Several potential sources ot 
error are eliminated, particularly 
data type and transaction for- 
mat mis-matches 


Most conventional workflow 
implementation errors occur 
because of application configu- 
ration and transaction data 
errors 


ICE™ applications cannot be 
further configured for workflow 
because they are already 
designed and implemented for 
workflow; transaction data 
errors are impossible because 
all applications are already 
viewing the same synchronous 
data 


har greater flexibility or naviga- 
tion, fewer errors, faster 
response times 


a workflow may be reversed 
(e.g., change an order into a 
return) by completing the order 
workflow and then invoking a 
return workflow 


A workflow may be reversed at 
any time by choosing a reverse 
navigation path. 


A business process may be 
reversed without needing to 
complete the first process and 
then to complete a counterbal- 
ancing process 
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A management overnde ot nor- 
mal workflow procedures that 

hae nnt Kaon thnmiinhk/ 

llab I1UI Uccll UlUJUU^IIiy looltSU 

risks violating business, data 
consistency and in some 
cases, even data integrity rules 


A management override of nor- 
mal workflow procedures 
involves invowng aiiornaie 
business methods which all 
obey the same data consis- 
tency and integrity rules. Even 
apparent violations of business 
rules (e.g., create a fictitious pro 
forma order with no customer 
and missing suppliers) will not 
corrupt data integrity or consis- 
tency. 


it is possible to perform unfore- 
seen tasks or to prepare non- 
conrorrning ^10 any existing 
workflow) quotations, pro for- 
masorbids. Entire transaction 
sets may be duplicated or re- 
routed to additional customers 
in a zero programming, zero 
workflow engineering environ- 
ment 


Accounting rules (e.g. (3AAP 
required double-entry book- 
keeping and transaction preser- 
vation) must be externally 
enforced through workflow, 
business and data consistency 
rules 


Accounting rules (e.g. GAAP 
required double-entry book- 
keeping and transaction preser- 
vation) are enforced by 
workflow and business method 
rules at point of entry 




bven in so-called "dynamic 
workflow modeling systems, 
the actual workflows are stati- 
cally bound to the operating 
environment 


in ICE™, all business methods 
are, in the object-based sense, 
dynamically bound to the oper- 
ating environment 


All let™ workflows potentially 
exist as un-executed but possi- 
ble entities 


By the time an exception solu- 
tion is implemented in a con- 
ventional workflow 
environment, conditions caus- 
ing ft have already have 
changed (e.g., the customer 
may not be a customer any- 
more!) 


Any workflow ts already poten- 
tially implemented in ICE™. 
When an exception arises, it 
can be dynamically responded 
to. 


instant response to exception 
conditions 


Conventional workflow applica- 
tions are ordinary task-based 
menu style programs adapted 
to an externally imposed work- 
flow framework 


ICE™ applications are actually 
logical views and methods that 
are initially architected and pur- 
pose-built to operate in a 
dynamic workflow environment 


No further setup or conditioning 
of applications is necessary in 
order to perform workflow func- 
tionality 


A major source of error in con- 
ventional workflow systems is 
data type mismatches 


All icb™ methods are logical 
views of the same physical and 
logical database— data type 
check errors are literally impos- 
sible 


All data in all applications tor all 
users is always current Data 
integrity and consistency are 
enforced in one place 


uata types (e.g., packed, 
numeric, zoned, alpha, bitmap) 
must be declared by a devel- 
oper 


uata types are automatically 
synchronized and reconciled in 
the ICE™ development envi- 
ronment—any and all type dec- 
larations when necessary are 
strictly automated 




conventional development 
environments have separate 
tools to enumerate change or 
enhancement impact. Adding 
an application can impact much 
of the existing system. 


i ne icb ™ development envi- 
ronment automates data type 
reconciliation and optionally 
can report the changes an 
enhancement may have 
caused. All applications use 
the same data consistency 
rules 
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Conventional tRP system 
architecture must be capable of 
supporting Fortune 100 enter- 
prises. Smaller implementa- 
tions must carry the design 
overhead of these architectures 


lut ,M is designed ana opti- 
mized for business instances 
requiring less then 125 GB of 
live transactional data and is 
able to radically reduce com- 
plexity and overhead (this does 
not rule out sunnnrHnn muttinle 
ICE™ instances in a single 
enterprise) 


let IM is optimized Tor your 
business, not for a multi-billion 
dollar multinational. You don't 
pay for all that overhead either 
in license and consulting fees 
or in performance 


Any business method in a con- 
ventional workflow environment 
is a physical appOcation that 
must be selected and adapted 
as a sou res and/or tarnet annli- 

cation in the workflow 


Any business method in ICE™ 
is potentially either a source or 
target method to all other meth- 
ods in a read mode, and is a 

Inniral ^nurrf* nr tarn At to most 

other methods in a create, 
update or delete mode 




Workflows are stnetly uni-direc- 
tional except for branches and 
loops. Even so, the workflow 
must end at a predetermined 
ending point. 


Workflows are all potentially bi- 
directional. For example, an 
order entry workflow may turn 
into an RMA (return material 
authorization) at any point sim- 
ply by taking the reverse navi- 
gation path. 





It will be appreciated by those of ordinary skill in the art that the invention 
can be embodied in other specific forms without departing from the spirit or essen 
tial character thereof The presently disclosed embodiments are therefore consid- 
ered in all respects to be illustrative and not restrictive. The scope of the invention 
is indicated by the appended claims rather than the foregoing description, and all 
changes which come within the meaning and range of equivalents thereof are 
intended to be embraced therein. 
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Subject: MegaNetworkNightly report (12/18/98 10:45 PM) 

Sent: 12/19 6:39 AM 

Received: 12/18 10:44 PM 

From: MeaalMiahtlv@meQanetwork.com 

To: chartesffmeqanetwQrK.cQm 

fohn@meganetwork.com 
kenny@meganetwork.com 

kimffmgqanetwQtt.cQm 
wendY^mfqgingtvygrK.gQm 

won@meaanetwork.com 



No reminders today 



Nightly Update Reports Follow 



All MWS numbers are in sequence. 



No MWS cancellation problems were found 



The following sales records had ord/rcv/shp date problems which were 
repaired succesfully. No other date problems found. 



M98-28538 11/5/98 



No MWSs with unit X qty price/cost problems were found. 



The following sales records have Hems that are received and not shipped. 



M98-28619 12/7/98 NoPartial UNION BANK OF CALIFORNIA 
M98-28632 12/9/98 NoPartial UNION BANK OF CALIFORNIA 
M98-28633 12/9/98 NoPartial UNION BANK OF CALIFORNIA 
M98-28639 12/11/98 NoPartial UNION BANK OF CALIFORNIA 
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Hi 

M98-26640 12/11/98 NoPartial UNION BANK OF CALIFORNIA 
M98-28657 12/17/98 NoPartial UNION BANK OF CALIFORNIA 
M98-28658 12/17/98 NoPartial UNION BANK OF CALIFORNIA 
M98-28659 12/17/98 NoPartial UNION BANK OF CALIFORNIA 
M98-28660 12/17/98 NoPartial UNION BANK OF CALIFORNIA 
M98-28662 12/17/98 NoPartial UNION BANK OF CALIFORNIA 

The following shipping records shipped in the last 7 days have defualt 
manifest frt totals. 

11/23/98 UPS Pickup*: 99076868 
11/24/98 CALL TAG Pickup#: 502960111 
12/1/98 CALL TAG Pickup#: 504632811 
12/4/98 0306-243219- Pickup*: 
12/11/98 UPS Pickup#: 200 monitor 
12/14/98 UPS Pickup#: 990768 
12/14/98 UPS Pickup#: 990768 
12/14/98 SECURITYEXP Pickup#: F71649 
12/14/98 SECURITYEXP Pickup#: F71650 
12/15/98 SECURITYEXP Pickup* : F7 1651 
12/15/98 SECURITYEXP Pickup*: F71 652 
12/15/98 UPS Pickup*: 990768 
12/16/98 SECURITYEXP Pickup*: F71 653 
12/16/98 SECURITYEXP Pickup*: F71 654 
12/16/98 UPS Pickup*: 990768 
12/17/98 UPS Pickup*: 990768 
12/18/98 UPS Pickup*: 990768 



The following RMAs have date or qty problems and were NOT fixed. 

R-272186CR 7/24/97 
R-274615XDM 8/12/97 
R-292761CR 12/22/97 



No RMA credit problems were fuond. 

The following RMAs have been received from customers in the last 30 days 
and need credit memos. 



R-321917CR Invoice: 12/1/98 
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R-322083CR Invoice: 12/15/98 
R-322118CR invoice: 12/16/98 
R-322267CR Invoice: 12/15/98 



No RMAs have been received from customers in the last 30 days that need 
replacement MWS attention. 

All customer invoices that have been printed have been issued. 
The following customer invoices are issued and not printed. 



UNION BANK OF CALIFORNIA 12/8/98 Paid in full 
UNION BANK OF CALIFORNIA 12/14/98 Paid in full 
UNION BANK OF CALIFORNIA 12/14/98 Paid in full 
UNION BANK OF CALIFORNIA 12/14/98 Paid in full 
SOUTHERN CALIFORNIA EDISON 12/16/98 
SOUTHERN CALIFORNIA EDISON 12/18/98 
UNION BANK OF CALIFORNIA 12/18/98 
UNION BANK OF CALIFORNIA 12/18/98 
UNION BANK OF CALIFORNIA 12/18/98 
UNION BANK OF CALIFORNIA 12/18/98 
SOUTHERN CALIFORNIA EDISON 12/18/98 



*=Old 




M7803 


Customer 


M7827 


Addendum 


*17828 


Addendum 


M7829 


Addendum 


*17845 


Customer 


*17857 


Customer 


17858 


Customer 


17859 


Customer 


17860 


Customer 


17861 


Customer 


17862 


Customer 



All items shipped in the last 30 days have been invoiced. 

The following customer invoices were found to have commission problems: 

M97-25714 10/15/97 for Charles commission & invoice GMs are different. 

17843 M98-28645 12/16/98 for VERNON commission & invoice GMs are different. 
17843 M98-28645 12/16/98 for KIM SEALE commission & invoice GMs are different. 



Commission dates were all found to be valid. 

All customer invoices issued in the last 90 days have 2 commissions. 

No duplicate vendor invoices were encountered. 
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All vendor invoice billed amounts equal payment register totals. 

All items received in the last 30 days have been fully shipped. 

The following MWSs have in house items that need to be ordered and/or received. 

M98-28657 12/17/98 
M98-28658 12/17/98 
M98-26659 12/17/98 
M98-28660 12/17/98 
M98-28662 12/17/98 
M98-28663 12/18/98 

All items on hold or cancelled are not on a payment register. 

All Vendor Payment Register payment amounts match Ven Invoice payments. 

All Vendor Payment Register credit amounts match Ven Collection amounts. 

All Vendor Payment Register Credits have been issued properly. 

No PrePaid Vendor Invoices were found on Non PrePay Vendor Payment Registers. 

The following vendor credits have possible duplicate expected credits. 

Exp-4478 00/00/00 Invoice: 

Exp-5185 00/00/00 Invoice: 50-10686-21 

All expected credits have an invoice assigned. 

All Vendor Invoices have payment schedules that match the Invoice total. 
All Ven Invoices are assigned to an AP Invoice Register. 
All Ven Collection records are assigned to an AP register. 
All Paid Ven Invoices are assigned to an AP Payment register. 
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All used Vendor Credits are assigned to an AP Payment register 



PCT/US98/27496 



The following MWSs have shipped in the last 30 days but are NOT fully or 
over invoiced, or not printed. 
*= New 



•M98-28573 Customer SOUTHERN CALIFORNIA EDISON Unprinted invoices 

'M98-28647 Customer SOUTHERN CALIFORNIA EDISON Unprinted invoices 

*M98-28649 Customer UNION BANK OF CALIFORNIA Unprinted invoices 

♦M98-28651 Customer UNION BANK OF CALIFORNIA Unprinted invoices 

'M98-28652 Customer UNION BANK OF CALIFORNIA Unprinted invoices 

*M98-28653 Customer UNION BANK OF CALIFORNIA Unprinted invoices 



No customer invoice tax problems were found. 

All unissued customer invoices were successfully issued. 

The following Customer Credits have no tax and are taxable. 
CM-10432-2-10 5/15/97 Restock 



Won Choi 

Mega Network, inc. 

Phone:(408)730-9138 x839 

Fax:(408)720-1293 

won@meaanetwork.com 
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What is claimed is: 

1 . A method of business-to-business transaction processing using a 
database and a database management system, comprising: 

receiving user demand information electronically; 

at least partially in response to receiving the user demand informa- 
tion electronically, automatically storing an order record in the database 
and maintaining the order record in the database throughout a life cycle of 
the order; and 

during the life cycle of the order, multiple users each accessing the 
order record and processing the order to accomplish a respective one of 
multiple business functions, and creating records related to the order. 

2. The method of Claim 1 , wherein the life cycle of the order includes 
an expected period for at least one of reversal, service, and parts order. 

3 . The method of Claim 2, wherein reversal includes customer returns 
and correction of improperly fulfilled or mistaken orders. 

4. The method of Claim 1, or Claim 2 or Claim 3, further comprising: 
providing within the database management system at least one of a 

table switch function and a related table switch function, wherein: 

the table switch function enables a user to freely view 

records of any of various tables except as otherwise prohibited by 

access authority defined by a supervisory user; 

the related table switch function enables a user to freely 

view records of any of various tables related to a selected record, 

except as otherwise prohibited by access authority defined by a 

supervisory user. 
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5. The method of Claim 4, wherein the related switch function is used 
to display information to a user via the Web. 

6. The method of any of the preceding claims, further comprising 
defining automated workflow processes for a plurality of business functions using 
the database and the database management system, wherein the workflow pro- 
cesses constrain user inputs and actions but allow use of at least one of the table 
switch function and the related table switch function. 

7. The method of Claim 6, further comprising allowing a user with 
proper authority to access all tables containing transaction-relevant information. 

8. The method of any of the preceding claims, further comprising pro- 
viding a central table supporting multiple business functions, whereby changes 
made by one user performing one business function can be viewed immediately 
thereafter by other users performing other business functions. 

9. The method of Claim 8, wherein the central table is an item detail 

table. 

1 0. The method of Claim 8, further comprising: 

users, in response to business events, entering information affecting 
Financials into the database; and 

posting general ledger entries in the database such that latency 
between entry of said information and posting of a corresponding general 
ledger entry is either negligible or not greater than a predetermined small 
time period. 
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1 1 . The method of Claim 1 0, wherein the predetermined small time 
period is one day, allowing for the preparation of substantially real-time financial 
reports. 

12. The method of any of the preceding claims, further comprising pro- 
cessing information stored within the database to provide functionality within a 
majority of the following categories: enterprise resource planning, sales force 
automation, supply chain management, purchasing automation and electronic 
commerce. 

13. The method of any of the preceding claims, further comprising: 
in response to receiving the user demand information electroni- 
cally, automatically storing a quote record in the database; 

receiving further user demand information electronically; 
in response to receiving the further user demand information elec- 
tronically, automatically converting a quote record to an order record. 

14. The method of any of the preceding claims, wherein the database 
management system is Web-enabled, and at least one of said user demand infor- 
mation and said further user demand information is received via the Web. 

15. The method of any of the preceding claims, further comprising a 
user retrieving a quote record that has not yet been converted into an order record, 
modifying the quote record, and updating the quote record. 

1 6. The method of any of the preceding claims, further comprising a 
user retrieving an order or quote record, duplicating the order record as a quote 
record, modifying the quote record, and saving the quote record as a new quote 
record. 
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1 7. The method of any of the preceding claims further comprising 
allowing a supervisor to view quotes created by subordinates of that supervisor. 

18. The method of any of the preceding claims, further comprising, for 
each of a plurality of users, storing within the database management system a plu- 
rality of favorite quotes of that user for ready duplication. 

1 9. The method of Claim 1 8, further comprising allowing a user to 
change that user's favorite quotes and effecting the changes on-the-fly in real time. 

20. The method of any of the preceding claims, further comprising elic- 
iting user demand information by displaying to a user products approved for pur- 
chase by that user. 

2 1 . The method of any of the preceding claims, further comprising elic- 
iting user demand information by displaying to a user a summary of products fre- 
quently purchased or recently purchased by that user. 

22. The method of any of the preceding claims wherein the user 
demand information includes at least one of installation instructions and shipping 
instructions. 

23. The method of Claim 22, further comprising automatically enforc- 
ing dependencies based on at least one of ship group and installation group. 

24. The method of any of the preceding claims, further comprising: 
automatically identifying quote records less likely to be converted 

into order records; and 

communicating with users so as to increase the liklihood of the 
quote records being converted into order records. 
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25. The method of Claim 24, wherein communicating with users com- 
prises automatically communicating with users via the Web. 

26. The method of Claim 25, further comprising automatically commu- 
nicating a promotional offer. 

27. The method of any of the preceding claims, further comprising pro- 
cessing via the Web a post-sale transaction relating to a product previously sold, 
comprising the steps of: 

a user communicating a request via the Web, causing a related 
record related to an existing order record to be stored; and 

processing the request using an automated workflow process. 

28. The method of Claim 27, wherein the post-sale transaction is one of 
the following: return, service, and parts order. 

29. The method of any of the preceding claims, wherein the existence 
of an open return request is automatically taken into account within a plurality of 
workflow processes. 

30. The method of any of the preceding claims, further comprising 
automatically approving a return request in accordance with stored criteria and 
communicating approval to a user electronically. 

3 1 . The method of Claim 30, wherein the stored criteria are modified 
by a user having authority to do so. 

32. The method of any of the previous claims, further comprising elec- 
tronically communicating status information to a user. 
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33 . The method of Claim 32, wherein the status information pertains to 
an order. 

34. The method of Claim 32, wherein the status information is commu- 
nicated upon receiving an electronic request at the time of request. 

35. The method of Claim 32, wherein the status information is commu- 
nicated upon the occurrence of a status change based upon a previous request. 

36. The method of Claim 32, wherein the status information pertains to 
a post-sale transaction request. 

37. The method of Claim 32, wherein the status information is detailed 
status information concerning payment or non-payment. 

38. The method of any of the preceding claims, further comprising: 
automatically classifying records of a given type into multiple clas- 
sifications for workflow processing; 

one or more users interacting with the relational database system to 
take a prescribed action with respect to multiple records having a particular 
classification. 

39. The method of Claim 38, wherein the records of a given type are 
classified into multiple classifications based on experiential criteria. 

40. The method of Claim 38, wherein a record may belong to a plural- 
ity of categories, the method further comprising sorting records in accordance with 
a hierarchy of categories such that a record belong to both a category higher in the 
hierarchy and a category lower in the hierarchy is sorted into a group of records 
belonging to the higher category. 
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41. The method of Claim 40, further comprising a user rearranging 
classifications within a hierarchy to effect a business purpose. 

42. The method of Claim 38, further comprising the relational database 
system not allowing the one or more users to take at least some actions other than 
the prescribed action with respect to the records. 

43 . The method of Claim 42, further comprising a user with requisite 
authority to take an action not allowed for other users not having the requisite 
authority. 

44. The method of Claim 38, further comprising: 

a user interacting with the relational database system to change 
information within a record; and 

automatically reclassifying the record. 

45. The method of any one of Claims 26-35 wherein the records of a 
given type are of one of the following types: customer invoices, vendor invoices, 

sold and return merchandise authorization requests. 

46. The method of Claim 45, further comprising: 
classifying item sold records; 
forming a group of particular item sold records; and 
creating a vendor order including a vendor order item correspond- 
ing to the group of particular item sold records and representing one or 
more units. 

47. The method of Claim 46, wherein forming a group comprises 
grouping and regrouping item sold records as many times as desired. 



item 
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48. The method of Claim 46, wherein each vendor order item is related 
to at least one item sold record created in response to receiving directly from a user 
user demand information. 

49. The method of Claim 48, wherein an item sold record represents 
one or more units, and an item detail record related to the item sold record is cre- 
ated for each unit. 

50. The method of Claim 49, further comprising: 
receiving one or more units of a vendor order item; and 

for each unit, changing an item detail record to indicate receipt of 
that unit. 

5 1 . The method of Claim 50, further comprising physically manipulat- 
ing a unit in accordance with a workflow process defined within the database and 
changing an item detail record of the unit to reflect the physical manipulation. 

52. The method of Claim 5 1 , wherein physically manipulating the unit 
comprises installing the unit within a larger assembly. 

53. The method of any of Claims 26-43 wherein classifying comprises 
identifying critical path items for fulfilling an order. 

54. The method of any of Claims 26-44 wherein classifying is per- 
formed on the basis of at least a plurality of the following: item, availability, instal- 
lation instructions, and shipping instructions. 

55. The method of any of Claims 26-45 further comprising breaking 
down items into multiple tiers, each successive tier including component parts for 
items of a previous tier, and creating a record for each component part. 
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56. The method of Claim 55, wherein classifying is performed on the 
basis of availability within multiple tiers. 

57. The method of Claim 56, wherein availability information within 
multiple tiers is obtained via the Web. 

58. The method of Claim 56, further comprising communicating avail- 
ability information to a customer and, if the customer desires, changing at least one 
of installation instructions and shipping instructions. 

59. The method of Claim 55, further comprising ordering component 
parts from a vendor, receiving the component parts, and assemblying the compo- 
nent parts into an item. 

60. The method of Claim 55, further comprising identifying suppliers 
for the component parts of at least one tier. 

61 . The method of Claim 60, further comprising ordering an item from 
a vendor and automatically communicating demand information to at least one 
other supplier of a component part of the item via the Web. 

62. The method of Claim 61, wherein communicating via the Web is 
accomplished by one of Web push methods and Web pull methods. 

63. The method of any of the preceding claims further comprising 
using the data in the database to perform systematic quantitative evaluation of at 
least one of employee performance, vendor performance and customer perfor- 
mance. 
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64. The method of Claim 63, further comprising at least one of an 
employee, a vendor and a customer remotely accessing the database and viewing 
its own quantitative performance data. 

65. The method of Claim 63, wherein said evaluation is based entirely 
upon data in the database. 



66. The method of Claim 63, wherein said evaluation takes into 
account reversals of orders. 
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67. The method of any of the preceding claims, wherein the user 
demand information includes, at least implicitly, vendor identification informa- 
tion, further comprising automatically transmitting corresponding order informa- 
tion to a designated vendor for fulfillment of the order. 

68. The method of Claim 67, further comprising automatically trans- 
mitting N-tier order information to multiple corresponding vendors. 

69. The method of Claim 1 , further comprising: 

displaying to a Web user multiple electronic commerce course-of- 
dealing options including at least one option relating to products and at 
least one option relating to payments; 

the Web user setting at least one electronic commerce course-of- 
dealing option in accordance with a choice of the user; and 

the electronic commerce system effectuating the choice of the Web 
user for each of multiple subsequent electronic commerce transactions. 

70. The method of Claim 69, further comprising effectuating the choice 
of the Web user on-the-fly in real time. 

71. The method of Claim 69, wherein displaying comprises displaying 
a multiplicity of electronic commerce course-of-dealing options in tabular form. 

72. The method of Claim 69, wherein course-of-dealing information is 
read during transaction processing of an electronic commerce transaction. 

73 . The method of Claim 69, further comprising: 
setting authorities of multiple Web users; and 

allowing a Web user to set an electronic commerce course-of-deal- 
ing option only if the Web user is authorized to do so. 
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74. The method of Claim 73, further comprising effectuating the set- 
tings on-the-fly in real time. 

75. The method of any of claims 61-64, wherein a second, working- 
level electronic commerce course-of-dealing option relates to the authority of a 
Web user to perform a predetermined action authorized in accordance with a first, 
enterprise-level electronic commerce course-of-dealing option. 
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76. The method of any of the foregoing claims, further comprising 
making remotely accessible to a user status information pertaining to each of a 
majority of the following product life cycle stages: purchasing, receiving, ship- 
ping, installation/assembly, billing, and returns/service. 

77. The method of any of the foregoing claims, further comprising a 
user executing a dynamic workflow process not explicitly provided for. 

78. The method of any of the foregoing claims, further comprising an 
external user remotely setting or changing authority of one or more users. 

79. The method of Claim 78, further comprising the system immedi- 
ately effecting the changes in authority. 
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42* 
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jMVS [Type 


|0ty 


Ord ! 


Re 


9691 


{M97-261 40 i Cus-pOK 


L 21 


19! 


1 


CS0381 
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i 9 < 
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KIM1 


}M93-*13897 FcusHNp 
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Items S 



Company - PO 


MVSNum |Qtu 


Ord 


Rcvd 


Shipd 


PACBELL ISG 


M-930008 NoP ! 1 


1 


1 




3 items 930107 


1/7/93 OriglShipd 


3/22/93 


3/22/93 




3 


DON B AKER PG.5 1 0-806-7459 






TBD 




LOCKED 


Jet Propulsion Laboratories jM-930003 NoP ; 1 




1 


1 


1 j 


2 items 000635262 


1/5/93. DestiShipd ^722/93 


3/22/93 


3/22/93 1 


1 


Deborah Williams (8 1 8) -397-7 1 84 i 






CmpLnd 


HAYSH527I 




LOCKED 












PA?f?LL ISG jM-930008 NoP I 1 




1 


1 


1 i 


3 items 9301 07 \ 1 /7/93 Orig IShipd \ 3/22/93 


3/22/93 


3/22/93 j 


2 


DON BAKER PG.5 10-806-7459 






CmpLnd 


HPCD r J62^ 




LOCKED 












\ \ 1 


1 


111! 




930107 


J /7/93 !Shipd 


3/22/93 


3/22/93 


3/22/93 j 


1 










CmpLnd 




LOCKED 


BEEBOY FILE 


M-930007 NoP ! 1 




1 


1 


i 1 i 


5 items XXXXXXX 


1 Z6/93 Orig IShipd i 3/22/93 


3/22/93 | 3/22/93 I 


5 


MAUDELLE(415) 751- 


4020 i 






CmpLnd 


APPL-1034( 




LOCKED 
















i 1 




1 


1 


* 1 j 




XXXXXXX 


1 Z6/93 IShipd" I 3/22/93 


3/22/93 


3/22/93"! 


4 




i 






CmpLnd 


APPL-H142 


LOCKED ** 






\ 1 




1 


1 


1 ] 




XXXXXXX 


1 /6/93 - IShipd \ 3/22/93 


3/22/93 


3/22/93 j 


3 










CmpLnd 


APPL-H142 


LOCKED " 


£y^E.?M:£L§YSTEMS^ INC. IM-930002 NoP ! 1 


1 


1 


1 ] 


1J*HB:L JJ ™ 3 1 1 2/29/9? Orig Ishipd 


6/3/93 


"3722/93" 


3/22/93 ! 


1 


Gerry Binkhorst (408) 982-3350 14444 






MicroD 


307535 


LOCKED 


MI9I.!:M IM-930007 NoP ! 1 1 




1 


1 j 


1 ! 


Iill m J?...„>?XXXXXX 1 1 /6/93 Orig IShipd ! 3/22/93 


3/22/93 | 


3/22/93 j 


2 


MAUDELLEC415) 751- 


4020 






CmpLnd 


APPL-Aoie 


LOCKED 




; 






1 | 


1 i 


1 i 
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old: 46989 Of 46989 (Sales-MWS) 



Description 



Cost 



Price 



CABLE 



8.00 



Igr 

CW 



ULTRA 144, 1 



EXT . V32 BIS 554.28 



595JD0 cvj 



p. 



POSTSCRIPT LEVEL II CARTRIDGE F/LJ 
HIP, Hi, HID 




* i SSL 



C2089A 



jLASE 
ISERI 

d" 



I 



iMAC 

Irchr 

5""" 



i iRECH 
(SYS1 



Select a status. 



lOEMr 



POVl 

ST 



Rel 



Status 



Cancelled 
Credit hold 

Direct ship from Mnfctr 
Discontinued 
Drop shipped 
Hand Dlvr 

Ignore on future reports 

In Transit 

Installation 

Lost in transit 

No record of order 

Not released new product 

On allocation 

Open source complete 

Open source required 

Order hold 

Other 

Partial ship 

Replacement 

Ship to wrong address 

Shipped 

Urgent 

Vendor follow up 
Wrong Product 



Cancel 



OK 
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1 

1 


jxpedite Status - exp date - cust notes 


CSR Note; 




jnore on future reports 

i — ........... — — — — 


FHJFHJG 




p/oo/oo 




?ck order ~ 










b/55/66 




Transit j 








5/66/65 




iore on future reports 






766 /66 




lore on future reports 

\ 










5/66/56 TESRT 




iore on future reports 

i__ 1 — 








1/66/65 




jore on future reports 










i/OO/OO 




tore on future reports j 

I 




%/93 




jore on future reports 

* 










1/00/00 




iore on future reports 
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Fig. 73 



Fig.73A 



Fig.73B 



Fig.73C 
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RMA- Orig- Pr 


Case No CS 


ExCr-RCred 


Ven-RMA* 


Ship-Rev 


R-265798RP 


Temp24563-1 


NoCredit 


compaq 


NA! 


Nemesio.ccc 


5/6/97 




97050607801 


NA! 




□ 




Warranty repair 


PI 5/14/97 05/06 


/97 DO A PRODUCT: PROVIDIAN (drop shi 


R-265876RP 


Temp24784-1 


5,996.70 * 


Microage 


5/12/97 


Brandon.aaa 


5/6/97 


5,996.70 


716376 


NA! 




□ 




Credit 


Fl 5/7/97 : under MV 8*24784, 740cdt is transferred from 


R-265914 


Temp24833-1 


8,449.00 


Merisel 


5/9/97 


Brandon.aaa 


5/8/97 


8,449.00 


4984009 


NA! 




□ 




Credit 


fl 5/8/97 THE CUSTOMER CANCELED THE ORDER 


, VE ARE CI 


R-266068 


Temp24833-2 


759.00 


Merisel 


5/9/97 


Brandon.aaa 


5/8/97 


759.00 


(4984009 


NA! 




ri 




Credit 


fl 5/8/97 THE CUSTOMER CANCELED THE ORDER 


, VE ARE Gi 


R-266177 


Temp24833-3 


13,524.00 * 


Merisel 


5/9/97 


Brandon.aaa 


5/8/97 


13,524.00 


4984009) 


NA! 




n 




Credit 


Fl vendor part*57156. 5/8/97 THE CUSTOMER CANCELED 1 


R-266295 


Temp24833-5 


69.50 


Merisel 


5/9/97 


Brandon.aaa 


5/8/97 


69.50 


4984009* 


NA! 




n 




Credit 


fl 5/8/97 THE CUSTOMER CANCELED THE ORDER 


. VE ARE Gi 


R-266374 


Temp24833-7 


2,508.00 


Merisel 


5/9/97 


Brandon.aaa 


5/8/97 


2,508.00 


♦4984009 


NA! 



Optii 



f~l Vendor Inv 





+ 



jPR° printed CS° cross Shpd Sort Sets | Searches I New Records 
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RMfl: 7 of 3186 (Sales-MID< 



fcust-Cust PO*-F^xed 


Rcv-Shp 


Inv-Crd 


Qty 


Description 


hRST DEPOSIT El 


NA! 


13143 


1 

0 


ARMADA 4131T 5/133 16 
NB4100 


jl 9497-401 67-N 


NA! 


3,628 


'Dispatched On-Site warranty service 


No Credit jDOA 


\ to compaq)IS TRYING TO GET IT REPAIRED THROUGH COMPAQ. COMPAQ WILL REP A 


NETWORK GENERAL C0Rl[3 


5/12/97 


13381 


1 
1 


TECRA 740CDT PENT-166 
13.3 TFT 10X 


(86091 


5/12/97 


6,195 


(Warranty repair/exchange 


No Credit I DO A 


)nv*233828. the item is DO A. we will replace with inventoru item (also from micro 


JMEDIATEL ( TODD MART^ 


NAI 




1 

0 


NETSERVER LH2 6/200 Ml 


5F970225 


NA! 


27,805 


[Not shipped to customer 


No Credit 




OING TO RETURN AS WRONG PRODUCT RECEIVED . 


'MEDAIATEL (TODD MAR'S 


NA! 




1 

0 


64MB MEM. EXP. MODULE f 


5SF970225 


NA! 


NC 


(No credit /no exchange 


No Credit 





jHNO TO RETURN AS WRONG PRODUCT RECEIVED . 



I MED I ATEL (TODD M ART I 
5F970225 



NA! 
NA! 



jNo credit /no exchange 



NC 

No Credit 



HOT SWAP DRIVE, 9.0GB ,F 



Hediatel (TODDDMAR'B 


NA! 




1 


ETHEREXPRESS 10/100 PC 


SF970225 


NA! 


NC 


0 


B 


No credit /no exchange 


No Credit ! 



)ING TO RETURN AS WRONG PRODUCT RECEIVED 



MED 1 ATEL 


NA! 




1 

0 


SURESTORE 12000E AUTOl 
SCSI 4MM DDS-2W/MANI 


.SF970225 


NA! 


-NC 


<5 M> S 

: Return RelatedSwitch QuickSwitch 




Approve 


Reset ] 


Not approved 


Not Required"] 
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MB 1400 12.1INCTFT 



t : 



□ 

□ Reqd □ Released 



{Hardware - Other 



□ Closed 



COMPAQ CASE 11 IS 97050607801 KYBC 



hMX 2.02GB 16MB 



□ 

□ Reqd Released 



' ! Hardware - Other 
r 



□ Closed 



yqe s/n -05720765, which already passed 30 



I 64MB RAM 
L 



□ 

["I Reqd □ Released 



□ Closed 



j/NETSERVER 60NS 



□ 

□ Reqd □ Released 



□ Closed 



I iR NETSERVER 



□ 

□ Reqd □ Rele ased 



□ Closed 



i TX ENET MODEL 



□ 

□ Reqd □Released 
□ Closed 



SADER EXT 48GB 
AL,CABLE 



□ 

□ Reqd □ Released 
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allow 
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Allow 
Return 




j >- 








ADow 
auto 
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c5 



Exceed agreed 
return period 


* | 


£ 1 


Days 




CO 

CD 




Exceed $ 
return limit 


Amount 
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Amount 


Amount 


Amount 




Service fee for 
On-site 


Range/Y/N 


Range/Y/N 


t 

cr 

co 
CC 


Range/Y/N 


Range/Y/N 


Range/Y/N 


CO 


Range 


d 


<T> 

cm 


cr> 
cn 

£ 






Max allow time = Vendor 
max time 
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<r> 
cm 
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CO 


cm 
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CC 
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em 
cr 

CO 
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Fig. 79 



Fig. 79A 
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Vendor File Auto RMA Approval 
Automatic Approval Criteria 



Return type/Action 
(C&V) 


Return allowed 


Allowable Max 
date vendor time 


Restock 
Fee 


1 

1. Credit 'Check 
l 


Y/N 


Limit 


Range 


[ Credit 
I card 


Y/N 


Limit 


Range 


1 Credit 

1 memo 
i 


Y/N 


Limit 


Range 


2. Exchange 
Mirror C&V 


Y/N 


Limit 


Range 


3. Repair/replace 
(on/off site) 


Y/N 


N/A 


N/A 


Mirror |Under warranty 
C & V | part/exchange 
I required 


Y/N 


N/A 


N/A 


I Under warranty 
J part not req'd 


Y/N 


N/A 


N/A 


■Out of warranty 
J part required 


Y/N 


N/A 


N/A 


lOut of warranty 
I part not req'd 


V/M 


M/A 


M/A 


4. Ship J wrong address 


Y/N 


Limit 


Range 


I 

1 Refused 
I 


Y/N 


Limit 


Range 


[Lost 


Y/N 


N/A 


N/A 


[Ship 
J damaged 


Y/N 


Limit 


Limit 
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l missing 
l components 


Y/N 


N/A 


N/A 


I Duplicate 
> ship 


Y/N 


N/A 


N/A 


l inventory 


Y/N 


N/A 


N/A 


5 | Cancel 
Never I order/shipment 


Y/N 


N/A 


N/A 


ship, • 

stoy in I Transferred 
ware- | order 


Y/N 


N/A 


N/A 


house "Never ship 
! to customer 


Y/N 


Limit 


Limit 


6. Not applicable 


Y/N 


N/A 


N/A 


7. Other 









New rules: 

1 . Return type must be create in duplicate (pair) for Vendor & Customer (V & C). 

2. Allow changes only of return detail on either V or C. One return detail must remain unchanged (crea 

3. Return type can be different for vendor & customer on the same RMA. 

4. Option to block use of any return type. 

5. Original ship date as guide for proper selection of return type. 

6. Create default setup initially. 
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Fig. 80 



Fig. 80A 



Fig. 80B 
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Mfr. File Auto RMA Approval 



Automatic Approval Criteria 



Return type/Action 
(C&V) 


Return 
allowed 


Open return 
allowed 


Max time to 
return 


Max time to 
Warranty service 
on-site 


Max time to 
Warranty service 
off-site 


1. Credit I Check 
l 


Y 


Y/N 


Limit 


N/A 


N/A 


] Credit 
I card 


Y 


Y/N 


Limit 


N/A 


N/A 


1 Credit 
• memo 


Y 


Y/N 


Limit 


N/A 


N/A 


2. Exchange 
Mirror C&V 


Y 


Y/N 


Limit 


N/A 


N/A 


IRepair/replace 
(on/off site) 


Y 




Limit 


N/A 


N/A 


Mirror JUnder warranty 
C & V | part/exchange 
l required 


Y 


N/A 


N/A 


Limit 


Limit 


lUnder warranty 
I part not req'd 


v 

i 


N/A 


N/A 


1 imit 

Ulllll 


1 imit 

Ulllll 


■Out of warranty 
1 part required 


Y 


N/A 


N/A 


N/A 


N/A 


lOut of warranty 
1 part not req'd 


Y 
T 


M/A 
IN/ A 


M/A 
IN/A 


M/A 
IN/A 


M/A 
IN/A 


4. Ship J wrong address 


Y 


N/A 


Limit 


N/A 


N/A 


I 

1 Refused 
i 


Y 


N/A 


Limit 


N/A 


N/A 


[Lost 


Y 


N/A 


Limit 


N/A 


N/A 


[Ship 
J damaged 


Y 


N/A 


Limit 


N/A 


N/A 
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1 . . 
I missing 

I components 


v 

T 


M/A 
IN/A 


M/A 

N/A 


M/A 

N/A 


M/A 

N/A 


I Duplicate 
'ship 


Y 


N/A 


Limit 


N/A 


N/A 


j Inventory 
" 


Y 


N/A 


Limit 


N/A 


N/A 


5_ j Cancel 
Never i order/shipment 


Y 


N/A 


Limit 

Ul 1 III 


N/A 


N/A 


el*™ i* 1 Transferred 
siay in ,|u|,b '«"«« 

ware- |«*f... 


Y 


M/A 

N/A 


N/A 


M/A 

N/A 


M/A 

N/A 


house l Never ship 
! to customer 


v 
T 


M/A 
IN/ A 


Limit 


M/A 

In/A 


M/A 

N/A 


6. Not applicable 


Y 


N/A 


Limit 


N/A 


N/A 


7. Other 


Y 


N/A 


Limit 


N/A 


N/A 



New rules: 

1 . Return type must be create in duplicate (pair) for Vendor & Customer (V & C). 

2. Allow changes only of return detail on either V or C. One return detail must remain unchanged (creation keys 

3. Return type can be different for vendor & customer on the same RMA. 

4. Option to block use of any return type. 

5. Original ship date as guide for proper selection of return type. 

6. Create default setup initially. 
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Fig. 82 





Fig.82B 


Fig.82A 
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Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 
Line 



LINE 
1(Col4) 
2(Col4):_ 
3(Col4):_ 
4(Col3):_ 
5(Col3):_ 
6(Col3) :_ 
7(Co13) :_ 
8(Col3):_ 
9(Col3):_ 
10a(Co13) 
10b(Col3) 



FORMULA OR FIELDS TO USE IN QUICK REPORT OF SALES TAX FILE 
JGrossSale - PriceCredit 
JnternalUse 



Linel (Co14) + Line2(Col4) 

Resale+Resale Adjust 

FoodProducts + Food Adjust 

Installation 

GovernmentSale + Government Ad jus 

OutOfState + OutOfStateAdj 

SalesTaxBilled 

BadDebt 

ResoldlntUse 

1 0c(Col3) : Returnedltems 

1 0d(Co13) : Discounts 

lOe box 60(Col3): not calculated 

lOe 61(Col3): Line lOe box 60(Col3)*0.8333 

1 0f<Col3) : Freight 



1 1 (Col4) :_ 
12(Col4):_ 
1 3(Col4) :_ 
14a(Col4):- 
14b(Col4):« 
1 5(Col5) 



Line 16(Col4);_ 
Line 17(Col4):_ 
Line 18(Col4):_ 
Line 19(Col4):_ 
Line 20a(Col4):_ 
Line 20b(Col3):_ 
Line 20b(Col4):_ 
Line 20c(Col3) 
Line 20c(Col4);_ 
Line 21(Col4):_ 
Line 22(Col3):_ 
Line 23(Col3):_ 
Line 23(Col4) 
Line 24(Col4):_ 
Line 25(Col4):_ 
Line 26(Col4);_ 



Schedule A 



. Sum of Line4(Col3) thru Linel 0f(Co13) 

.Line3(Col4)- Linel 1(Col4) 

. Linel 2(Col4) * 0.06 

. Linel Oe 61 (Col3) + Linel 2(Col4) 

.Linel4a61(Col4) * 0.0025 

.Not calculated 

. Line 1 4a(Col4) + Line 1 5(Col4) 
. Linel 6(Col4) * 0.01 

. County Tax (Register gets amount from sum of Col8) 

. Linel 3(Col4) + Line 1 4b(Col4) + Line 1 7(Col4) + Line 1 8(Col4) 

.OutOfStatTxPaid 

. County TaxableT* 

.Line 20a(Col3) * 0.0075 

. County Taxableft 

.Line 20c(Col3) * 0.0075 

.Line 19(Col4) - Line20a(Col4) - Line20b(Col4) - Line20ca 
. Actual prepayment from 1st prepayment register. 
. Actual prepayment from 2nd prepayment register. 
.Line22(Col3) + Line23(Col3) 
. Not calculated 
.Not calculated 

.Line23(Col4) + Line24(Col4) + Line25(Col4) 



Line A1(Col4): 

Line A2/A3(Co14): 
:Line A4(Col4): 



Counties(Col3) : 
Counties(Co16) : 
Counties(Col7) : 
Counties(Col8) ; 



_Line16(Col4) 

_ GrossSale+lnternalUse 

_LineA1(Col4) r LineA2/A3(Col4) 

. County TaxableTt 

. Counties(Col3) 

. Tax Table 

.County Tax (Register gets from Counties(Col6) * Counties(Col7)) 
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Fig. 83 



Fig.83A 



Fig.83B 
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Invoice-Dat e-Term-Tu pe 


Customer ¥ Customer PO 


13195 


ORACLE 


13/24/97 


N30 


C. RODRIGUEZ (41 5) 506-3209 


i Customer 


(415) 633-2945 




238078 j 


(Printed 


STxPaid 


AR Posted R^263436CR (Temp2462(h 1 ) Approved : 


13204 


FIRST DEPOSIT j 


13/26/97 


N30 


LINDA (415)222-7669 


{Customer 


DS 


(415) 278-6045 


1 9620-43935-N j 


IPrinted 


STxPaid 


AR Posted &-263681RP (Temp24646- 1) Approved: 


13231 






APPLIED MATERIALS 




1 


13/31/97 


N30!Denise Fritsch (408) 563-1 240 I 


1 Customer 


1(408) 563-5504 


4500020574 1 


IPrinted 


STxPaid 


AR Posted S/&/97: fixed inv. list to denise. 5/i 


13261 




I CHEVRON INFORMATION TECHNOLOGY 


14/3/97 


N/30[Meiane Nock-Salgado 510) 842-071 6 | 


1 Customer 


DS 1510)328-1710 


FSRA 2006326 j 


IPrinted 


STxPaid 


R-264144RP (Temp246 1 Closed: 6/ 


13300 




IGasonics International 






14/9/97 


N30 i Dana Senqeush (408) 570-7366 


\ Customer 


1(408) 570-7350 




31646 


IPrinted 


STxPaid 


R-264277XDM (Jemp247\2- J ) Approve 


13307 




1 NETWORK GENERAL CORP. 




1 


14/10/97 


N30iVIN ROHDES (415) 473-2061 i 


[Customer 


1(415) 327-3961 




86035 | 


IPrinted 


STxPaid 








13359 






APPLIED MATERIALS 






14/17/97 


N30 1 Denise Fhtsch (408) 563- 1 240 


[Replacement 


1(408) 563-5504 


4500020574 j 


IPrinted 


STxPaid 


R-263744XSM (Temp24625-1) 6/6/9 








^ ifi iS 




i 

1 


OptionsI 9«1 


+ 












Q FastDsply Sort 


Sets Search New Records Ret 


4 lllll 



FIG. 83A 



WO 99/33016 



PCT/US98/27496 



iCust-lnuoices: 7 of 15258 (Sales-Mi 



MVS /qty- Total 


PO- Invoiced 


Left to pay Uae 


Frt-Tx-RMA 


M97-24620 


238078 


Closed-Paid I Age: 65 


89.43 


1 ,634.43 


1 ,634.43 


: 
! 


Out of state 


£il/i?.i:5L kL5^2f/?7. V: PAID IN FULL 





!M?7 T 24646 [l 9620 : 43?35 T N j C]osed : Paid | Age : 36 j Destination 



.469.81 






jP: 469.81 L 


: 5/1/97 V: PAID IN FULL 


| 


* 4/ 15/97 


;M9772462|5 

!6,226\69 


14500020574 j C]ose<HPaid 

16,228.09 i 


j Aje : 70 [42.16 


P: 6,228.09 


L: 6/9/97 V: PAID IN FULL 





IM97-24618 


IFSRA 2006326 jOpen 


I Age: 379 11,569.79 I 


,251,936.83 


J?44,363/72 j 


118,503.93 j 


jP; 244,363.72 


L? 4/1 8/97 V ! " PAiD In FULL 


ZZ1 1 i 



! i'5/y? R-263925RP <Temp246 1 0-2) Closed: 6/5/97 4/15/97: Jim Welsh 5)0-642 



|M?7-247I2 [31646 jClosed-Paid iAge:58 110.14 

j 1 84.42 j j 84.42 * [ [ ] T ! \\32B 

i P :. 1 84.42 L : 6/6/97 " ' V : " PAID IN FULL I 



i 



^9:4/ 17/97 5/29/97 :RMA involved ne*d to findRMA type, need to credit $10.14 
'M97-247I3 [86035 i Closed-Paid I Age: 25 ! 12.03 



304.72 l?04;7!... 

P : 3 04 /7 1 " * * " L : 5 / 5 < /' 9 7 ' ' * vT 



[22.31 



PAID IN FULL 



M?7 7 24760 


!45G0020574 




j Age : 56 [30.11 | 


4,55K7Y' * 


..." j^sV^r^' 




J |^f($9"!"" J 


P: 4,551 .71 


L: 6/12/97 " vT 


pam> in full 





•7 riarvw ^ill CM- 1323 1-1 -73 $4500.72 inr$4S51 .71 to deduct from inv end pay the 



5 i* 1 



: urn RelatedSwitch QuickSvitch 



Total & Collect 



Notes 



( De-Is 



Searches 



Poj 



FIG. 83B 



PCT/US98/27496 





Credit summary 












I 

: 
| 




| 


?mse 




^ 1453 -> SttcUi GoWsiein 510^04^X60 1 ieftmso. 4/ i f/97: e-mail £ } 




it curbs' * fault 










difference ($50 Jf) ^26B744XSM/ Terrv>24625-1 6/4/91 






»sue ] Sales Ad j Historical On J 




st ][ Reoalc ] Delete ] 




!► 





FIG. 83C 



WO 99/33016 



WO 99/33016 / w PCT/US98/27496 



Fig. 84 



Fig.84A 



Rg.84B 



Fig.84C 



WO 99/33016 



PCT/US98/27496 



Invoice-Date-Term-Ty pe [Customer 



¥ Customer PO 



10840 



{SILICON GRAPHICS INC 



16/22/96 

> 

I Customer 



N301 ACCOUNTS P AY ABLE 
[(4 1 5)96 1 -1 35 1 



(415)933-6381 

6ici6i4866 



IPrinted 



&-250S72RP (Tewp2259ChO Approved 



10843 

[6/22/96 

> 

I Customer 



[first deposit 

'N3p|LiNpA^' ' ^* " 

[(415)278^045 



(415) 2227766? 
16796-32726-21 01 



IPrinted 



10844 

16/22/96 
» 

ICustojrner 
iPrinted 



[ORACLE 

N45[C.R^ 

[(415)' 633^2945* 



(415)5q6 : 32q? 

26911 




Options! <|p Ggi] 



□ FastDsplu Sort Sets 




+ 

JLJL 



Search 



New Records 



Re! 



FIG. 84A 



WO 99/33016 



to A* 



PCT/US9S727496 



Cust_lnvoices: 3 of 15258 (Sales-MWS) 



/qxy- iota I] 


ru- invoicea 


l«tt xo pay |Aqe 


Krt-Tx-RMA 


M96-22590 


01 CI 01 4866 


Closed-Paid jA9e:46 


^ORIG No Frt 


4,794.88 


367.43 




^26.43 ! 


P: 367.43 L: 8/7/96 V: PAID IN FULL 





Totals (3 invoices 0 credits) 



Total Credits 




Net invoiced 


4,261.52 


Total sales 


3,923.00 


Total Tax 


245.31 


Total Installation 


50.00 


Total Freight 


43.21 


Paid to date 


4,261.52 


Credits taken to date 




Net received 


4,261.52 


Not paid 




Credits not taken 




Net receivable 



nation 
»8 



f state 




FIG. 84B 



WO 99/33016 PCT/US98/27496 



to\/ky 



Credit summary 









ssue 



Sales Adj 



Historical On 



Recalc 



Delete 



33 



FIG. 84C 



WO 99/33016 



PCT/US98/27496 



Fig. 85 



Fig.85A 



Fig.85B 



Fig.85C 



WO 99/33016 



PCTYUS98/27496 



Invoice-Pate-Term-T^ pe Customer 



¥ Customer PO 



1 0840 

16/22/96 

» 

! Customer 



S IL JCOH GR APH ICS INC 

ACCOUNTS PAY ABLE ' * ' ] * " * " * (4 1 5)933^638)** ][] 
(41 5)961 -1351 01 CI 01 4fl66 



N30 



iPrinted 



&-2S0572RP (Te/rp2259<h1) Approved 



10843 

[6/22/96 

> 

'Customer 



[FIRST DEPOSIT 

" N3o[l jljlD A 

K^Ys) ^8-6045 



^(415)222 : 76j59 
16796-32726-2101 



IPrinted 



10844 



! ORACLE 



Totals (3 invoices 0 credits) 




ORACLE 

SILICON GRAPHICS INC 


1 
1 


1 ,050.21 
367.43 


0.00 
0.00 


1 ,050.21 1 ,i 
367.43 





Options 




□ FastDsply Sort Sets 




+ 

JUL 



Search 



New Records 



Re< 



FIG. 85A 



WO 99/33016 



PCT/US98/27496 



Custjnvoices: 3 of 15258 (Sales-MWS) 



M*s> /qxy- loiai 


ru- invoiceo 


ueTT \o pay |Aqe 


Krt-Tx-RMA 


M96-22590 


01 CI 01 4866 


Closed-Paid | A^e : 46 


ORIG No Frt 


4,794.88 


367.43 


I 


26.43 


P:367.43 L:8/7/96 V: PAID IN FULL 





nation 
38 



i i 



total iTax total | Inst total [Freight total [Paid to date |Credtis taken |Net received 



307.00 
341.00 



0.00 
26.43 



0.00 
0.00 



43.21 
0.00 



1 ,05021 
367.43 



0.00 
0.00 



1 ,050.21 
367.43 



>30%3 



>60 886 j 



urn RelatedSvitch QuickSvitch [L 



JCUI tllC) 



De-Is 



FIG. 85B 



WO 99/33016 



PCT/US98/27496 



I Credit summary" 



1 ! 




0.00 
0.00 



0.00 
0.00 



0.00 
0.00 



90 869 1 | Collection 8ecj 



OK 



Sho\N 











•sue 


[ Sales Adj 


Historical On 




- ) 


Recalc ] 


Delete 









FIG. 85C 



WO 99/33016 PCI7US98/27496 



Fig. 86 



Fig.86A 



Fig.86B 



WO 99/33016 



2\o A* >" 



PCTAJS98/27496 



Amount 


Cust Inv Total 


Cust Crd Total 


Balance 


35,038.01 


40,062.44 


-5,024.43 




C Paum+nf ) 


Invoice Disb 


Credit Disb 


Disb to Cash 


Bal 


40,062.44 


-4,967.05 


-57.38 



CustPayments 



ESL/TRW-ASG 

Check: 429069 1/17/95 



Stub -> Payment distribution (red=Credit, 

grau bckarnd=Not Reconciled ita1ir<:=sNM C Wod^ 



C 



J 



W 



Check Stub Ref ?Re1 Inv j Applied to jTgpe jstub Atnnt [ Applied Amnt j 



4731 


4731 


14731 


Invoice I 


24,866.28 


24,866.28 \ 


4737 


4737 


[4737 


Invoice j 


5^646.75 


5,646.75] 


4829 


4829 


14829 


Invoice ! 


9,549.41 




DM32890 /4829 1 


4829 


ICM-4829-1-; 


, Credit i 


-1,749.86 


-1,749.86] 


DM32889/4695 ! 


4695 


|CM-4695-3-< 


Credit ! 


-467.64 


-467.64J 


: : 
: i 


i 


i 


t : 


t 


i 



DM 



Invoices applied (gray bckgrnd=short pay) 


Credit memos applii 


Invoice 


Date jrlVS 


inv Amnt jDstrbtd \p; 


Credit Memo 


D< 


4731 


112/06/94 [M94-17130 


1 24,866.28! 24,866.28 i 2- 




CM-4829-1-31 


2 


4829 


: 1 2 / 1 3 /94 j M94- 1 7204 ' 


9,549.41 F 9,549.41 | < 




CM-4695-3-49 




4737 


! 1 2/06/94 ! M94-1 7135 


^ 5,646.75*1 5,646.751 ! 












i L 
























X 


+. 




JUL." 



FIG. 86A 



WO 99/33016 



PCT/US98/27496 



CustPayments: Modify Recon 



Created by 




Jhu Jinn 


01 /20/95 



K| Reconciled 



Approved 



| Posted 



AR Voucher number 




Notes 



DM32889 INVOICE 4695 PAID 
ON CHECK 429068 
DM32888 /4737 
AMT$2806.93 CM$2806.92 



?d (red=Debit Memo /gray bckgrnd= Issue) 
ite i Credit jDstrbtd ( Taken Tt 



5/4 /95 F * 467J64T 467 mT" 467.64 



EE 



ir !::: U 



FIG. 86B 



WO 99/33016 



~ta for 



PCT/US98/27496 



Fig. 87 



Fig.87A 



Fig.87B 



WO 99/33016 . PCT/US98/27496 

in A) r 




Ov 



Reference red=unreconc<led I Customer 



429069 

i 


Check 


Reconciled 


ESL/TRW-ASG \ 


430068 


Check 


Reconciled 


ESL/TRV-ASG ! 




095150 


Check 


. . i NETWORK GENERAL CORP. ! 


, . , 


000023541 SCheck 


i 

................ .. i 


PACIFIC BELL LOS ANGELES ! 


( — 1 


0613394 

i 


Check 


: 
: 


Symantec Corporation i 



! 1 



I 



i 



Sort s » ts Search Total Return R#la 



FIG. 87A 



WO 99/33016 , PCT/US98/27496 



terUnderPay: b of 98 ^g|pf-MU» ^= 


[ Disc rep en cy Amount red=customer owes 




• .ui uver v#reoit 


_C7 TQ l*t4pB>Mj4 n Dt<ir\Aki 

Of .5o imurea or. of o&qvqdx 


■ o.oo UYer credit 


inxurea .ui ts&CwwX 


: t*rO.A3 UVvr UreOlT 




! 734 .59 Over Pay men* Closed 




[8^508.05 Over Credit 




i 

z ,..„„„,„„ 
















j^Rl 1 | Options | 
itedSwitch QuickSwitch 



FIG. 87B 



WO 99/33016 / PCT7US98/27496 



Fig.88 



Fig.88A 



Fig.88B 



WO 99/33016 PCT/US98/27496 



r 3 File Edit Enter Select Reports Mega; 



Amount 

227,253.67 


Cust Inv Total 

227,253.67 


Cust Crd Total 


Balance 


LtAii P*u<n+n1 ] 


Invoice Disb 

227.211.59 


Credit Disb 


Disb to C 

42.08 


Bal 227,253.67 



CustPayments 



FIRST DEPOSIT 
Check: 218510 



7/21/95 



Stub 



> Payment distribution (red=Credit, f 

orau bckornd=Not Reconciled . ita1ic;g=Not Cleared^ ^ 

Check Stub Ref IRel Inv [Applied to jType iStub Amnt 



5015 


| 5015 


5015 


Jnvojce J 


163.66. 


5487 


| 5487" 


5487 


Invoice | 


46635' 


5846 


5846 


5846 


Invoice 1 


4,210.54 


6127 


6127 


6127 


Invoice I 


445.55 


6128 


6128 


6128 


„.._—-....-„„........ 

Invoice 1 


446.65 


6129 


! 6129 


6129 


Invoice ! 


2,658.9? 




6139 


6139 


Invoice \ 


2,990.74 





Invoices applied (gray bckgrnd=short pay) C 


|4?53 


Date 


MVS 1 Inv Amnt j Dstrbtd j Pi 


i 


5015 


12/28/94 


^94-174051 163 .66 { 163.66! 


5487 
5846 


02/10/95 
03/21 /95 


M95-17874] ' 466.60 j 466 : 60i tti 


6127 


04/07/95 


8406! 445.55 | 445.55 ! ' 




|4|lIIl| ► 


X 



ULJ... 



..*..lU 



0 



FIG. 88A 



WO 99/33016 



PCT/US98/27496 



Activities 



iCustPayments: Modify Record 



Created by 
Thu :nnn 



07/24/95 



Reconciled 



IaI Approved 
^Posted ~ 



AR Voucher number 



1 



Notes 



Applied Amnt j Rec jC 



163.66 



466.60 



4,210.54 



445.55 



446.65 



2^658.99 



2,990.74 



:redit memos applied (red=Debit Memo /gray bckgrftd= Issue) 



"redit Memo 


Date 


Credit iDstrbtd I Taken Tt 






: i 








: 

r : i 






r L, L 






i i 






1 ; 




»■ \> 



•<_.F„j'..j 



It tt 





FIG. 88B 



WO 99/33016 



PCT/US98/27496 



Fig. 89 



Fig.89A 



Fig.89B 



Fig.89C 



WO 99/33016 PCT/US98/27496 





Invoice -pay -Yen /terms 


In -En -Ry 


MVS /qty - cost 


PO -billed 


1-5237969 


10/3/96 


o INVENTORY* 4 




ITECHDATA 


10/7/96 


5,600.00 


5,600.00 


iTECHDATA 


N30 r 




JP : 5 .600 .00 L: 5,600.00 ,,,,12/5/96 „ 














50- 


01138-21 




2/5/97 


M97-24410 1 


24410 




MicroD 


12/11/97 


41.69 


\ 41 .69 




MicroD 


N30 12/7/97 


P: 41.69 L: 41.69 


3/5/97 *9375 




AP Posted 


236139711 


2/10/97 


Multiple 8 


\ 

j 


IDEUTSCHE-PLS 


2/14/97 


6,441 .52 


I 6,441.52 




MjcroD 




2/1J/97 _ 


^P: 6.441 .52 L: 6/41 .52 3/5/97 « 








AFPosied 


need cr. $35.00 




11- 


38282-1 1 




6/5/97 


Multiple 10 




! Merisel 


6/9/97 


777.40 


1 777.43 


! Merisel 


N30 


6/6/97 


P: 777 .43 L: 777.43 7/25/97 *97 














13- 


32564-1 1 


16/1/97 


M97-24919 1 


| 24919 


i Merisel 


16/9/97 


360.24 


j 360.24 



! Merisel 



N30I6/6/97 IP: 360.24 L: 360.24 7/5/97 «965 



1.01 2 [5/21./97 t j Expenses 

RX I LANIER ELEC . " ' ^ ' ' " \'\&/ m \ Q/97 * J* ^ . " | * " ^ * 
LANIER ELEC N30 fod/bo/ob IP: 900*00 



L: 900.00 



900,00 
6/19/97 



*96 



H £ d 



Duped 
< 1 11 ] 



□ 

□ Vendor RMA 



Sort 



Sets Find New Records 



R> 



FIG. 89A 



WO 99/33016 PCT/US98/27496 



b=^iUen-lnuoice$: 6 of 27234 (Sales-MU 11111111 


Next payment | Status-problem |RMA -Vcredit 


Disc-Dt-f-Ls 


! jPaid-Ord j 


10/3/96 
Avail : 




[*9157 R: multiple V : j 



i 



I ]Paid : cRM A T BC ;R:25742?CR ] 2/5/97 

' 1 ^04042Hr ] Avail: 

I I jj-i-ffaSjpJ?. .V. ; ^ | $41 *69l 



! jPaid : Cre<HBC jMultiple ] 2/1 0/97 

i j iMultipli? 1 Avail: 

[93E72 !?J..n?.yliiP.]!L... M V.L ' \ $225. 1 1 i 





6/5/97 

Avail : ] 




08 R: multiple V: 


i ««........«.. 

I 


j iPaid-Ord i 


6/1/97 ! 

Avail: I 

j 


I : j 


4 R: multiple V: ! 


j Building maint j Avail: I 



2?_ 



>turn RelatedSvitch QuickSwitch 



Total Billed 
Need to pay 



Remo | 



Hisl 



FIG. 89B 



WO 99/3301 6 PCT/US98/27496 



MSB 


Cust Inv Stats Reviev Status 


Date - Pay - Voucher 




Inventory [Or d] 


1 1 /2/96 - 5,600.00 - 








12965 ! [Cred] 


3/7/97-41.69- 






Multiple j [Cred] 


3/5/97-6,441.52- 






S Multiple [Ord] 


7/5/97 - 777.43 - 


I 

I ~ 




13535 i [OrdJ 


7/1 /97 - 360.24 - 


1 
1 
t 




No Invoice ! [[rx]J 


6/20/97 - 900.00 - 






1 1 1 

VB F,et,<ml [ Act Distribution ) 


tortcaion [ Set Partners Acts ] 


LI 





FIG. 89C 



WO 99/3301 6 PCT/US98/27496 



Fig. 91 



Fig.91A 



Fig.91B 



Fig.91C 



WO 99/33016 



MM: 



PCT/US98/27496 




FIG. 91A 



WO 99/33016 



r 



PCT/US9S727496 



Uen_lnuoices: Modify Record 



[ Payment Schedule"] 



Search 



Interest 



Inv Date 

5/15/97 



Misc. 



Mega Voucher No 



Date Rcvd 

5/21/97 



PAY g|Pai<l 
11 J 84.50 



Mega PAY 



Next Pymnt 



jRMA/OP jRp/SP ICust tnvjCust /Terms 




15/16/97 
|.?2! 6/97 1 5/1 6/97 


13462A j SILICON GRAPHICS INC 
■ j CredrtCard | 


i 15/19/97 
15/15/97 15/19/97 


*13468fl j SILICON GRAPHICS INC 
ICreditCard 


| 15/ 1*6/97 
[5/15/97 15/19/97 


134689 


SILICON GRAPHICS INC 
CreditCard 








! I 




i 



it Distribution ] 





FIG. 91B 



WO 99/33016 




PCT/US98/27496 



I 




i 



FIG. 91C 



WO 99/33016 



PCT/US98/27496 



Daily Uendor Uerification 



Found 



10/16/97 3:13PM 



Done 



62 



Miscelaneous invoices (includes pre-approved) 



Clean with RMA full credit) - cRMA 



Clean with Credit Memos (not RMA) - cCred 



Clean reconciled by Credit 
Clean inventory - clnvent 
Clean internal use - clnt 



cRBCr 



20 Clean manually reconciled - cMan 



3] Clean replacements - cRpI 

j Clean drop shipments - cDS 
24 | Completely Clean invoices - cC 
'53] 



Total clean invoices 



2 ! No MWS - NoMWS 



65 | Not reconciled (includes pre-approved) - NR 



11 j Replacement/RMA without credit - Cred 



Not received discrepencies - Rcvd 
Not shipped discrepencies - Shpd 



8] 
14] 



No customer invoices - Custlnv 
Freight/tax charges - FrTx 
Order date discrepencies - Ord 



Cost/Price discrepencies - CP 



99 | Total invoices with discrepencies 



120 



Not reconciled (not including pre-approved) 



86 



Reconciled 



Pre-approved 



Approved 



Scheduled 



215 



Total not paid 



( Reuerify ) ( Print ) ( Cancel j ^ Shom^ 



FIG.92 



WO 99/33016 . PCTYUS98/27496 



Fig. 93 



Rg.93A 



Fig.93B 



Rg.93C 



WO 99/33016 



PCT/US98/27496 



VenPmntRegs L Annr „™. 


[ Anprnvv ] 


□ Discount! Rate ! Disc | B Paid/Posted 


( Poij/IHrot ] 


Register 330 


Total Inv 169.158.72 


Register has been 
paid and cannot be 
modified 


Date 10/15/97 


Total Cr 5.392.84 


Count 93 


Net pan 163,765.88 


C Move ] IS Credit Reconciled C Reconcile J 


[ Notes ] 



Pay« 



I Vendor I Invoice 



IBilled Amnt jPue date j Amount 



ATV 



lATV 



t 2^4647[ 22,401. 25; .10/22/97] 22,401.25; 



DEUTSCHE-F! S YNNEX 



1894476! 



..Hi^9lJ.9/Ji/?l! $\660\ 1 



DEUTSCHE-F! S YNNEX 


1897681! 


1,109.00! 10/18/97! 


1,109.001 




DEUTSCHE-FI MicroD 


234107611! 


. 530.60! 10/15/97! 


530.60! 




DEUTSCHE-f ! MicroD 


234107621| ' 


170.28! 10/15/97! 


170.28j 




DEUTSCHE-F! MicroD 


2341170111 


1,530.61! 10/15/97! 


K530.61? 




DEUTSCHE-F! MicroD 


2349126111 


1 ,431.80! 10/16/97! 


1 ,431 .80! 


Invoice count 93 




Total Invoice ! 


169,158.72! 


Payee [Vendor 


[Credit Memo jTotal Credit IDate [Credit 


TECHDATA {TECHDATA 


2-82857011 


934.001 4/2/97! 


934.00 


Multiple 


TECHDATA iTECHDATA 


2-86624091 


96.00! 9/29/971 


96.00 


Price Protect* 


TECHDATA ITECHDATA 


2-8666105! 


1.410.00? 9/30/97; 


1 .410.00 


Credit count 1 8 


DO Reconciled 


Total Credit! 


5,392.84! 



56031 



: 5 '■ \ 

:i; :!'! 

:V.::u:%:::::i ] 



>»::u:::::^r. >i:t:iiiiti:i: 



4* 



f;:n:i:::u::. r;::::::::::::. 

I # ! il *j i 

« * « i :: * « t 



G 



FIG. 93A 



WO 99/33016 



PCT/US98/27496 



jUen Pmnt Regs: Modify Reconj 




ATV 
DEUTSCHE-PLS 
Merisel 
MicroD 
TECHDATA 



Vendors 



ALL 
ATV 
CmpLnd 

DEUTSCHE-PLS 

Merisel 

MicroAge 



Method iPaq Ref 



! Check 



Pate jVoucher 



9883 10/15/97 



Check 



9884 10/15/97! 



Check 



9884 10/15/971 



[Check 



9884 10/15/971 



I Check 



9884 10/15/97! 



I Check 



9884 10/15/97; 



jCheck ! 9884 10/15/97! 

! I Comments 



(M|hIo*» Pish ]f 



Disb 



Net Pan /Coll Total: 163,765.88 



Payee 



ATV 

DEUTSCHE-PLS" 



Merisel 



MicroD 



TECHDATA 



VIKING COM 



VESTMICRO 



[ Print Drafts ] r ° 



[ Chncfc } I 



Quid 



Payee 



Debit Vendors ) 





c 



FIG. 93B 



WO 99/33016 




PCT/US98/27496 



Payable To: 



ursement Reoist«»r 


Ref/Chk 


Amount Date 


[ 


i 20,619.33 ! 




i 

r — 


* 7,303.46 | 


i 


t 3,073.72 I 


i 


3,857.75 f 


r — 


j 23,609 ,62! 


L 


1,140.00 i 




, 4,162.00 i 




j 

















! apply qu,ck checks I Print , Check$ 

drag to the ^ ■ 
bisbursement Reg [ K+prirt Ch+«k 


k Checks (orphans) 


Ref/Chk 


Amount 


Date 


i 














































I 

I test 



FIG. 93C 



WO 99/33016 



PCT/US98/27496 



Fig. 95 



Fig.95A 



Fig.95B 



WO 99/33016 % PCT/US98/27496 



r 3 File Edit Enter Select Reports Mega Activitle; 



Defaults | a 


Cash Account 
Checking (>=Debit) 


Payroll 

Commssions Account (>=Debit) 


|l010|CashinBank *1 | 


16000 Salaries - var. | 


Accounts Receivable 

nK ACCOUnT v'— ueDlv 


Accounts Payable 
AP Account ^ >=Cr ediO 


1 2 1 0 | Trade Acct Receivables I 


(2010 Trade Accounts Payable | 


Net Sales Income Account (>=Credit) 
4010 | Sales Income 


Cost of Goods Sold- Goods (>=Debit) 


[5006 (Cost of Goods Sold (Goods) 


Tax Income Account (>=Credit) 


C0& Invoices 
Tax COG Account (>=Debit) 


2310 ISales Tax Payable I 


Freight Income Account (>=Credit) 


|50O7 Cost of Goods Sold (NonGoods ji 


Freight COG Account (>=Debit) 
15007 (Cost of Goods Sold (NonGoods]: 

Misc. COG Acct (>=Debit) 
|5007 |Cost of Goods Sold (NonGoods] : 


4090 | Shipping and Handling I 


Labor Income Account (>=Credit) 


|4075 | Service Income | 


Misc. Income Acct (>=Credit) 


Interest COG Acct (>=Debit) 
15007 (Cost of Goods Sold (NonGoods] i 
Freight Invoices 
Shipping Expense Acct (>=Debit) 


|4070 |Misc. Income | 


Bad Debt Expense Acct (>=Debit) 


|8030 |Bad Debt Expense 


Returns / Allowances 

□ Direct Write Off Method 

Returns /Allowance Acct (>=Debit) 


7170|Shippin<i 1 


Returns / Allowances 
Purchase Returns Acct (>=Credit) 


1 201 0 1 Trade Accounts Payable 


|4060 | Sales Returns /Allowance 


Purchase Discounts Acct (>=Credit) 




|5006 | Cost of Goods Sold (Goods) | 




>i:::sns::!'. >i::::iii:ku*. 

i M» II ! 4« ii 



Accrued Expense act is under here 
for possible future use - ungroup 



FIG. 95A 



I 



WO 99/33016 / PCT/US98/27496 



^faults: Modify Record! 



.ccounting Setup 



Credit Card(AR) 
Credit Card Expense Acct (>=Debit) 
17410 iBank Charges | 
Cr Card Accrued Income Acct (>=Credit) 



4015 



Credit Card Accrued Income | 



Accrued AP Account (>«Cr edit) 



GL Closing 
Retained Earnings (>=Credit) 



|3900 | Prior Year's Retained Earning 1 



2050 [Accrued Pag able 



C] Multi accrued payable - OFF 



: Expense Invoices 

: Tax Expense Account (>=D*hifl 


|To expense 


1^4 Expense 


i Freight Expense Account (>=DebifJ 


|To expense 


13 Expense 


: Misc. Expense Acct (>=D*bin 


• I |To expense 


I l&l Expense 


: Interest Expense Acct (>=5ebi* , i 


To expense 


M Expense 


: Inventory Support 




Account for Cust Purch Inventory 




MEGA CUSTOMER INVENTORY | - 




Account for RMA Inventory 




MEGA RMA INVENTORY 




Merchandise Inventory (>=Debit) : 




1 1 41 0 (Merchandise Inventory 



Check Amnt Pad 



1 it Ei 

\m\\?.i 



....! 





FIG. 95B 



WO 99/33016 0 .///i,v PCTAJS98/27496 




WO 99/33016 



PCT/US98/27496 



Fig. 97 



Fig.97A 



Fig.97B 



WO 99/33016 



PCT/US98/27496 



Acct Code 


Account Red ° not opened 


Account Type 


BA 1010 


Cash in Bank * 1 


Asset 


BA 1210 


Trade Acct Receivables 


Asset 


BA 1220 


Notes Receivable 


Asset 


BA 1240 


Other Receivables 


Asset 


BA 1250 


Employer's Loans and Advances 


Asset 


BA 1410 


Merchandise Inventory 


Asset 


BA 1510 


Prepaid Expense 


Asset 


BA 1520 


Pepaid Fed. Corp. Tax 


Asset 


BA 1530 


Prepaid Franchise Tax 


Asset 


BA 1610 


Furniture and Fixtures 


Asset 


BA 1620 


Office Equipment 


Asset 


BA 1630 


Class Room Equipment 


Asset 


BA 1640 


Vehicles 


Asset 


BA 1650 


Leasehold improvement 


Asset 


BA 1710 


ACC. Depreciation - F&F 


Contra Asset 


BA 1720 


Acc. Depreciation - Office Equip. 


Contra Asset 


BA 1730 


Acc. Depreciation - Class Room 


Contra Asset 


BA 1740 


Acc. Depreciation - Lease Hold 


Contra Asset 


BA 1750 


Loans to Shareholder 


Asset 


BL 2010 


Trade Accounts Payable 


Liability 


BL 2020 


Auto Loan - Current 


Liability 


BL 2030 


Loans Payable 


Liability 


BL 2040 


Interest Payable 


Liability 


BL 2050 


Accrued Payable 


Liability 



Finance Codes 




Search 



m 

New Records 



Retur 



FIG. 97 A 



WO 99/33016 / PCT/US98/27496 



ChartOfHccnts: 96 of 96 (Sales-MU 



j Increase 


Decrease 


Balance 


| Debit 


Credit 


644,025.30 


.Debit 


Credit 


855,100.21 


i Debit 


Credit 




{Debit 

1 


Credit 




j Debit 


Credit 




: Debit 


Credit 


15,569.00 


j Debit 


Credit 




j Debit 


Credit 




rrrr 

i Debit 
i 


Credit 




Debit 


Credit 


- 


| Debit 


Credit 




! Debit 


Credit 




Debit 

• 


Credit 




* Debit 


Credit 




Credit 


Debit 




.Credit 


Debit 




Credit 


Debit 




Credit 


Debit 




; Debit 


Credit 




Credit 


Debit 




• Credit 


Debit 




Credit 


Debit 




.Credit 


Debit 




Credit 


Debit 






OuickSwitch 



FIG. 97B 



WO 99/33016 



PCT/US98/27496 



Fig. 98 



Fig.98A 



Rg.98B 



WO 99/3301 6 PCT/US98/27496 




Fianancial Code IP 
Account Code 4010 
Account type Revenue 



Account Sales Income 



Date 



Account Titles and Explanation 



5/14/97 



Net sales for 5/14/97 



4/10/97 



Net sales for 4/10/97 



4/1 1/97 



Net sales for 4/11/97 



4/11/97 



Net sales for 4/11/97 



6/10/97 



Net sales for 6/10/97 



"I 



14" 

JUL 



EE! 



FIG. 98A 



WO 99/33016 



PCT/US98/27496 



k account j □ Credit card account 



O Debit to Increase (•) Credit to Increase 





Ref 


Debit 


Credit 


Balance 






547 




27,854.00 


27,854.00 


□ 




554 




30,791.37 


58,645.37 


lllil! 

iiiiii 
11 

III! 

Ml: 

iifili 
iiiiii 

iiiiii 
iiiiii 

iiiiii 

1 

1 




558 




42,015.00 


100,660.37 




557 




635.00 


101,295.37 




558 




115,568.00 


216,863.37 
















































































































lipii 

<> 
















Curr 


ent ballance 


216,863.37 


Setup 



FIG. 98B 



WO 99/33016 PCT/US98/27496 



Fig. 99 



Fig.99A 



Fig.99B 



WO 99/3301 6 PCT/US98/27496 



flccts_Rcuable: M 



Rccts-Rcuable 



Customer 



Company Name: 

ORACLE 



Receivables Acts { V Set Def ) 


Freight Income. 


Accounts Receivable (>=Debit) | 




Freight Act; 


V Trade Acct Receivables J 


V Shipping an- 










W 


Sales Income Acts C V Set Def } 


Labor Income l\ 


Sales Acts (>=Credit) 


<> 

s 

111 




Labor Acts 


V Sales Income 


V Service Inc 






<v 




Tax Income /Pay able Acts C_ V Set Def 3 


Misc. Income A 


Tax Acts (>=Credit) 




Misc Income 


V Sales Tax Payable 


V Misc. Incon 









USE 



4 

JLJL 



FIG. 99A 



WO 99/33016 PCT/US98/27496 




Setup 



Company Code: |Seq*: 
Oracle I 1 23 



/Pag able Acts ( V Set Def 
s (>=Credit) 



d Handling 



payable Acts ( V Set DeT 



(>=Credit) 



ome 



,cts 



I V Set DeT" 



? Acts (>=Credit) 

^e 




5 
+ 



Sales Rep Code: 
R J. CASTRO 



(op 



en Account 



□ Credit Card Acct 
O Inventory Acct 




FIG. 99B 



WO 99/33016 



PCT/US98/27496 



Fig. 100 



Fig.lOOA 



Fig.lOOB 



WO 99/33016 PCT/US98/27496 



Account ( Red a approved) 


GL Act 


BEEBOY FILE 








NAVAL SUPPLY CENTER 








V ATKINS JOHNSON 








NASA AMES RESEARCH CENTER 








CITY OF MOUNTAIN VIEW 








UNITED AIRLINES 








Symantec Corporation 








ORACLE 


Sales Income 






Silicon Systems 








US2 NAVAL WEAPONS STATION CA 








PAC BELL EDI 








Goldman, Sachs 














Delete Sort Sets Search 


f Get Inventory 



Get Credit Card * 

v R. 





FIG. 100A 



WO 99/33016 



PCT/US98/27496 



\ Customers: 1 2 of 903 (Sales-Mli j 



i Current Balance 


30 


60 


90 


i 
































222,304.12 
















7,553.00 
















104,288.00 
















623.510.96 
















j 763,048.50 








i 








i 4.372.277.53 
















1 w 499,156.82 
















13,239.00 








i 
























133,896.08 









































^ iff 



Options I 



»turn RelatedSwitch QuickSwitch 



FIG. 100B 



WO 99/33016 PCT/US98/27496 



Fig. 101 



Rg.101A 



Fig.101B 



WO 99/33016 



PCT/US98/27496 




Recounting 



Company Name: 

ORACLE 



Date 



4/10/97 



4/11/97 



4/11/97 



Account Titles and Explanation 



Customer Invoice 1 3308 issued 



Customer Invoice 13320 issued 



Customer Invoice 13326Jssued 



Addresses 



Df 


Type 


MVS Company name 


Contact 




Other 
VrHs€ 


ORACLE 
ORACLE 

rtn am r 




( Notes 1 f Del 



FIG. 101A 



WO 99/33016 PCT/US98/27496 



odify Records 



Information 



Company Code: 
Oracle 



Seq*: 

123 



Sales Rep Code 
R J. CASTRO 





Ref 


Debit 


Credit 


Balance 


o 




554 


2,294.90 




2,294.90 


ii :■: 
Hi: 

jjjjjj 

$11 

\W 
i t>: 

111 

:'• 

It til; 

t :*! 

Hi! 

U: 
I Ik 

m 

iii 
If 

i it; 
t.t?: 




556 


378.88 




2,673.78 




556 


38.97 




2,712.75 






































































































Current ballance 


2,712.75 






Address 1 | 


City 


O 


500 ORACLE PARKWAY p 
500 ORACLE PARKWAY f 


Redwood City 
fcedwood City 


H 

Ijliii 

o 



ete ) (^Duplicate ) f Edit ] f 



Add 




FIG. 101B 



WO 99/33016 PCT/US98/27496 



Fig. 102 



Fig.102A 



Fig.102B 



WO 99/33016 



2*3 /<} 



PCT/US98/27496 




Partner Name 



Partnei 



Accounts Payable (>=Cr edit) 


(✓Set Def) 


Accrued Payables ( 


■/ Trade Accounts Pay able 


H 




-/ Accrued Payable 




m 


+a 







* 








-m 




COG Accounts (>=Debit) 


(✓ Set Def] 


COG Misc. Account: 


V Cost of Goods Sold (Goods) 


e 
m 


+m 


V Cost of Goods Sold 


__ 








i 


-m 




COG Tax Accounts (>=Debit) 


(✓Set Def] 


COG Interest Accot 


V Cost of Goods Sold (NonGoods) 






V Cost^of Goods Sold 




r 

Is 








Hill:! 






p> 






COG Freight Accounts (>=Debit) (/Set Def ] 




V Cost of Goods Sold (NonGoods) 


e 








m 








iiiii 






<> 


-a 













( test ) 



^9 

a a \ a » 



JLJL 



FIG. 102A 



WO 99/33016 PCT/US98/27496 



able: Modify Records 



Hpproued 



- Code 



Credit Pagee 

MicroD 



:>=Credit) ( ✓ Set Def ) 




SUendor 

□ Manufacturer 

□ Carrier 



[El Payee 



g(>=Deblt) (y Set Def) 
(NonGoods) K>| 



I ill "^"^^ 
a- 



mts (>=Debit)(y Set Def) 
(NonGoods) Km 



El Cost of Goods Payee 



□ Expense Payee 
□ State Tax Payee 



Reserved space for 
more expense payees 



□ Automatic Invoice 



Open Recount 



Reset Defaults 



5 
+ 



[AP Subledger 



Setup 



Acrd Pay able] ( Acrd Invoice 



O 





FIG. 102B 



WO 99/33016 PCT/US98/27496 



Fig. 103 



Fig.103A 



Fig.103B 



WO 99/33016 



PCT/US98/27496 



Code 


Partner Name 


Red= BaseLine vendor 


MicroD 


Ingram MicroD 




i [>3 Aprvd 


(800) 274-4800 


I3 Ven □ Mfgr □ Car *Kl Payee 


CmpLnd 


Computer land 




! I§1 Aprvd 


(800) 354-9368 


El Ven □ Mfgr □ Car Payee 


Merisel 


Merisel 




flS Aprvd 


(800) 462-5241 


[3 Ven M Mfgr □ Car ]§j *Pauee 


Meqal 


Mega Netvork. Inc. 


> K Aprvd 


(408) 730-9138 


H Ven □ Mfgr □ Car t% Payee 


YordMarc 

fKI Aprvd 


VordM ARC International Corporation 


800-835-2400 


IS Ven □ Mfgr □ Car M Payee 


MICROCNTDL 


MICRO CENTRAL. INC 


: L/>J npr Yg 


800-836-4276 


Ven □ Mfgr □ Car K| Payee 


VMI 


VMI CORP 


! Kl Aprvd 


408-745-1700 


C3 Ven Mfgr □ Car ffi Payee 


IBM 


IBM CORPORATION 


\ C3 Aprvd 


408-452-4810 


K Ven Kl Mfgr □ Car Kl Payee 


ICG 


International Compute 




! £>3 Aprvd 


(800) 659-4244 


Kl Ven □ Mfgr □ Car I53 Payee 


compa^ 


Compaq 


! £3 Aprvd 


(800) 231-9977 


IS Ven Mfgr Fj Car Kl Payee 


VARDBAGY 


VARD-BAGY PKG INC. 




(408) -262-2111 


K| Ven □ Mfgr □ Car (53 Payee 


AZERTY 


AZERTY INC. 






IVI I | Mfnr- J j Pin Pan** 




Delete /Maint Sets 





€5 

Search 



+ 

JLJL 



New Records 



ii 

< 

Re* 



FIG. 103A 



WO 99/33016 PCT/US98/27496 



Partners: 1065 of 1065 (Sales-MU 



Accounts payable 


Acrued payable 


Total payable 


Accrued Invoice 










□ Expense ^ COG 


Cost of Goods Sold (Goods) 




i 1 


□ Expense [3 COG 


Cost of Goods Sold (Goods) 




I 1 


□ Expense [3 COG 


Cost of Goods Sold (Goods) 




1 1 


□ Expense O COG 


Cost of Goods Sold (Goods) 





I i 


El Expense □ COG 






1 L 


□ Expense £3 COG 


Cost of Goods Sold (Goods) 




1 1 


IS Expense □ COG 






1 1 


□ Expense IS COG 


Cost of Goods Sold (Goods) 




1 1 


t2 Expense Kl COG 


Cost of Goods Sold (Goods) 




1 1 


H Expense (S COG 


Cost of Goods Sold (Goods) 




L 1 


[^Expense Q COG 






1 L 






5 c c 

urn QuickSvitch _ 


J Vendors Locked 






Approve ] 


| Options | 



FIG. 103B 



WO 99/33016 



It* far 



PCT/US98/27496 



Fig. 104 



Fig.104A 



Fig.104B 



WO 99/33016 



PCT/US98/27496 



flccts_Payable: N 



1 flccts_Payable 




Partner flee 


Partner Name 1 

Ingram MicroD 1 



Date 



Account Titles and Explanation 



3/27/96 



To record received items without invoice. 



i 



FIG. 104A 



i 



WO 99/33016 



PCT/US98/27496 



lodify Records 



rued Payable (Received mithout Inuoice) 



Partner Code 


Credit Payee 




"licroD 


MicroD 





Ref 



580 



Debit 



Credit 



3,661.53 



Balance 



3,661.53 



!'<!>: 



Iiiiiii 
pi 



m 

iiiiiii 



Accrued payable balance 



3,661.53 



Current Accounts Payable 
Current Total Payable 



11,632.14 
15,293.67 



SI 



AP Subledger 



Setup 



Acrd Payable 



Acrd Invoice 




FIG. 104B 



WO 99/33016 



PCT/US98/27496 



< 




WO 99/33016 PCT/US98/27496 




WO 99/33016 



PCT/US98/27496 



to far 




WO 99/33016 PCT/US98/27496 



Fig. 106 



Fig.106A 



Fig.106B 



WO 99/33016 PCT/US98/27496 



Gen-Journal: 58 c 





uaie 


Account Titles and Explanation 


CAR 


O/ 16/7/ 


Cash in Bank *1 






Irade Acct Receivables 


546 




To record cash received to AR 5/1 3/97 


CM 7 


S / 1 A /OTP 
3/ 1 4/7 / 


Trade Acct Receivables 


E47 




Sales Income 


CA 7 
O** / 




Sales Tax Payable 


547 




Shipping and Handling 


547 




To record Customer Invoices issued 5/14/97 


548 


5/15/97 


Cash in Bank *1 


548 




Trade Acct Receivables 


548 




To record cash received to AR 5/15/97 


549 


5/19/97 


Cash in Bank * 1 


540 




Trade Acct Receivables 


540 




To record cash received to AR 5/1 9/97 


SSD 


5/23/97 


Cash in Bank * 1 


590 




Trade Acct Receivables 


590 




To record cash received to AR 5/23/97 



Cosh Rcpts Jrnl 




Search 



<>1 mi 



Manual Entry 



FIG. 106A 



WO 99/33016 



PCTYUS98/27496 



if 58 (Sales-MWS) 





Post R^f 




Credit 




1010 


1 Q1Q OA 

1 i y.o*t 






1210 




1 ,91 9.84 












1210 








4010 


1 


27,854.00 




2310 




2,298.98 




4090 




30.77 












1010 


74,615.40 






1210 




74,615.40 












1010 


59,649.38 






1210 




59,649.38 












1010 


11,804.31 






1210 




11,804.31 











<5 "fisP is? I ^g^^D 

Return RelatedSvitch QuickSvitch l Sho ^ E«Pl«natiog 



mm 



m 

111! 

1 

i| 

iilllf 
m 

tjiiii 

ill 
m 

Ml 

m 

Mi 



Mm 
W 

m 

If 

jii 

ijiii! 
iip 

iilH! 

II 



M 



El 



FIG. 106B 



WO 99/33016 



PCT7US98/27496 




WO 99/33016 



PCT/US98/27496 




WO 99/33016 PCT/US98/27496 




c 



0) 

£ 

0) 



in 

0) 

E 
o 
o 



O 
Q. 

® 



"O 

(13 
0J 
X 



5 mi.? 



10/ 



I* 



at 



■si 



vt: 
iffli 



m 



1 
3 



< 

QO 



9r 

Of 



t 

at 
a 
O 



WO 99/33016 



PCT/US98/27496 




WO 99/33016 PCT/US98/27496 



m/br 



§ 

CD 

.£: 



V: 



01 



5 



41 

tec; 



cq 



.Si! gj 

a. 
s : ai 
3:0 



3* 



ai j 

oi § 



-Si 



fa 



WO 99/33016 PCT/US98/27496 




Q 

0O 



g 




WO 99/33016 



PCT/US98/27496 



Ll 



< 


CO 






o 


o 






6) 


d> 


iZ 


LE 



WO 99/33016 



PCT/US98/27496 



O 
O 

d 
o 

o~ 
o 



o 
o 

d 
o 
o 

d 
o 

CM 



o 
q 

d 
o 

d 
o 



o 
o 

d 
o 

CD 

d 
o 



o o 
q q 

d d 
o o 
o q 

o d 
o o 



o 
q 

d 
o 
o_ 

o~ 
o 



o 


o 


o o 


q 


q 


q q 


d 


d 


d d 


o 


o 


o o 




o 


o o 


d 


d 


o"d 


o 


o 


o o 




CM 





o o 
q q 

d d 
o o 
qo 

do 
o o 



CD 
C 

<d 
> 

CD 

Oi 



cd 

CD 
Q 



CO 
» 

c 

O 

o 

CO 
TO 

CO • • 

w 52 

O W 



CO 

0 



CO 

8 

c 

§ 

o 
75 

c 

CO 
CO 

E 

D 
Q> 

^ CO 
CO (1) 
CD 7£ 
-3 CO 

CO — 
o 

z 



2 
o 

CO 

•a 
o 
o 

a* 



CO 
O 

o 



O OI 

q q 

d d 
o o 
o o 

do* 
o o 



O 
*u. 
CD 
Q. 

O 

JS 

CO 

if 

2 
c 

CD 
> 

.E 

CD 
CO 

TJ to 
5 © 

CO CO 
JC CO 

o x: 
<5 B 

5 £ 



CO 
CD 
O 

! 

CO 
CO -rj 

§1 

§1 

CD 2 
CO 

co a) 

-C CO 
U CO 

°- 1 

co 0- 

co 

CD 



c 
o 

CO 
co o 



=3 

z < 



T3 
O 

CD 
Q. 



CO . 

o o 

-»— I 

a> S 

« z > 

$.2 = 

o > w 

o 8-5 
8 °^ 

a) o $ 
ZOJ 



ON 



2 
o 
co 

co 

§ S> 

O) CO 

o 

*- CO 

CO w 

O o 

o<5 



WO 99/33016 



PCT/US98/27496 



O 
O 

d 
o 
q 

o" 

o 

co ^ 
i 



o 
o 

d 
o 
cq 

d* 
o 



o 
q 

d 
o 
o 

d 
o 



o 
q 

d 
o 
cq 

d 
o 

CO 



o 
q 

d 
o 
q 

d 
o 



o 
o 

d 
o 
q 

d 
o 

o o o o o o o 
o o o o o o o 



o o o o o o o 
o o o o o o o 
cq o o o o cq q 

o~ dodo d* d 
o o o o o o o 




CO 
CD 
0) 

c 

CD 
Q 
X 
CD 

O 

s 

CD 
Q 



CO 
CD 
CO 

c 

0) 
Q. 
X 
CD 

CO 

c 
g 
"co 

CO 

E 

E 
o 
o 

"D 

c 
co 

Q_ CO 
X « 
<D CO 

o>© 

C CO 

= CO 

CD 
CO 



co 

CD 
CO 

c 

CD 

x co 

<D CD 
CO 
O) C 
C CD 

| 3- 

1£ CD 

| c 



CD C 

x 9- 

CO _ 

J s 

Q- = 
CO^ 



CO co 

CD CD 

CO CO 

C C 

CD CD 

CL Q. 

X X 

CD CD 

C D) 
O C 

co "55 

'o CO 
CD ^ 

Q- J2 

CD 

QO 



CD 
> 

O 
CD 
CO X 
CD CD 
CO „ 
C CO 
CD CD 
CL CO 
X C 
CD CD 

a> 8- 

CD 

CO CO 
iz CD 

.2 'S 

c i5 
•F CO 

< 



CO 

CD CO 



CO 
CD 
CO 

c 

CD 
CL 
X 
CD 



CO CD O) JO 



CO 
CD 
CO 

c 

CD 
Q 
X 
CD 

"O 

c 

CO 



u w c - 
CD c .2 

Q. CD CO m 

<d ® o a 
o w _ o 

c .a) « ff 

1^1 

CO 3 

— CO CD 

E 
o 
o 
c 



CD 
> 



2 

CD 
Q 
O 

c 
o 



CO 
CD 
3 



CD CD 

> 3 

- CD C 

C *- <D 

" si 



CD ^ 
CD 2 
O 



CO 

0 

CO 

C CO 
CD CD 
Q_ CO 
X C 
CD CD 

o>§- 
.£ ® 
2 "55 

ceo 



CD 



WO 99/33016 



PCT/US98/27496 



Fig. 110 



Fig.HOA 


Fig.HOC 


Fig.HOB 


Fig.HOD 



WO 99/33016 



PCT/US98/27496 



2 

o 
u 

u 

< 

2 
c 

C 



(0 
4 



1 uj 
CO 



3) 



T3 
C 
0) 



IS) 



w 
H 
c 

0) 



o 
e 



® 



e 

o 















* 






u. 


U 











01 
X 

E 

3 

mi ii i ,31 













u 








ni:::i 






•f" 




>ld| 



! i 



! ! 



o 



WO 99/33016 PCT/US98/27496 



VI 
M 
C 



9 



< 



lo 



I CD 'CO 



tt> - 
*>: — 



CLj CO 

«: a. 

O.ICL 



oio 

— ICvJ 



Z3 \ 

„_ i o> 

He 

7 !U_I 



o o 

— jCM 



Ei 

o • 
<r> : O 



Ui> 



o o 

vO jvO 



<T:<l!<r:<I:<tj<t!<ti<::<i::-<I 
CQiCO:QQ:GD:GQ:CQ:0Q!CQ:0Q:CQ 



WO 99/33016 



PCT/US98/27496 



E 
o 
o 
QC 

.SIS 

oio 
' \ I 

c|c 
o ; o 
'^\~ 
» jo 

o jo 

V t V 
k- : k. 
a.* o. 
0> ; d> 

. 1 



<i !<i :<r 



0- OiO 
— :C\I:K> 

1 — =i — 



<r ! <: i <r i <r 

CO ICQ ;C0 ICQ 



O: ' 
O i c 
o : ca 

0,1—1 

"Si o 



— ■CM 

ojo 

CVi!<SJ 



CL 



pn jcq i co i CO 



CO 



CO 



o io 

CO*: — 

— \tn 



io 



io ;o 

ILO !<M 
■CM'K) 



MM! 
— i I — i ; — i j — i ; — i io*) 

CO iCO 'CO 'CO 'CO ICQ 



o 
o 

K) ITT 



in 



9) 




C 








' — « 





















WO 99/33016 PCIYUS98/27496 



Fig. 111 



Fig.111A 


Fig.111B 


Fig.111C 


Fig.111D 


Fig.111E 


Fig.111F 



WO 99/33016 PCT/US98/27496 



IV far 



Trend Test 


Line 

Add Delete 


Column 


Field 




+H — B| ( Headers ] 

Add Delete 


(Clear] 








Plot labels: If 


Cash in Bank *1 


Trend analysis for: ! 


3- Cash in Bank «1 




i 







I 



FIG. 111A 



WO 99/33016 



KTTrend Analysis 




Start Date 
End Date 


Pick 


Pick 




O Portrait 


(§) Landscape 



j Trade Accounts Payable 



Trend frequency. 



r 



Veekly 
Monthly 
Quarterly 
Annually 
Specify Dates 



4 



OK 



FIG. 111B 



WO 99/33016 



PCT/US98/27496 



Reports used (Links) 


Used by : 




<> 




<> 




o 




o 


i Chart of Accounts 





17110 


{Office Expense 




ie 


; 6020 


j Officer wages 


BA 


! 1240 


! Other Receivables 




IE 


16110 


i Payroll fax Expense 


J* 


Hi 

DL 


i 91 on 


\ Payroll Tax Payable 


Ij!;!; 

*!':** 


~ba" 


M520 


] Repaid Fed. Corp. fax 




IE 


17130 


| Postage and Courier Services 


fi 


BA 


! 1510 


I Prepaid Expense 




BA 


j 1530 
T3900"" 


Prepaid Franchise fax 


iiiiii 


"BS" 


] Prior Year's Retained Earnings 


lib! 


IP 


!5020 


! Purchase Discount 


\&- 


IP 

_..„._. 


15030 


1 Purchase Returns 


I*!;!; 

jljUt 
fi!:-: 




15005 


! Purchases 


jjijt- 


IE 


17010 


i Rent 


li 


Te" 


17040 


_ ] Repai rs and Mai ntenance 


1:.: 


Te'* 


[6010 


\ Salaries - Fixed 


!;! :* 


IE 


16000 


j Salaries - var. 


f 


BL 


12060 


jSalary payable 


t 


IP 


14020 


j Sales Discount 




IP 


14010 


! Sales Income 




Jp" 


I4060"'" 


1 Sales Returns/Allowance 




BL 

Te""' 


12310 
17180 


i Sales fax Payable 

j Security " 


*.!* 

•i 


IP 


14075 


1 Service Income 




IE 


17170 


j Ship pi ng 




IP 


14090 


j Shipping and Handling 


11 


IE 


19010 


JState Income fair Expense" 


i 


BL 


12360 


! State Income fax Payable 


iii!: 

;hh\ 



FIG. 111C 



tar/or- 































































i <$» li II ®& Ml 



FIGo HID 



WO 99/33016 



PCT/US98/27496 

























































































o 


10 


X 





i 



FIG. 111E 



WO 99/33016 PCT/US98/27496 



IE 17140 
IE TjzSST^ 




Taxes - Othe rs " 


Si 
!>!>;: 

iBS 
§8 

iilii! 

iiiiiii 
iilili 

s 


IE 18150 


Taxes - Penalty 


IE 17030 
!rT875~4""''' 
mTT?9899~" 

l'r"!9999'9"' 

..„._._.., 

IFI'7999'"" 


Telephone 

Test 

TEST 3 

TEST EXPENSE 


BL 12010 


T rade Acco u nt $ Pa ga ble 


BA j 1 2 1 0 i Trade Acct Receivables 
TE"l*7350™"Tf7aveT 


IE 17020 ! Utilities 


o 


to ' 0 




Reiucivft Account [ Missing 



[ CPAs )( AB ) [ AP ) 



FIG. 111F 



WO 99/33016 PCT/US98/27496 



Fig. 112 



Fig.112A 



Fig.112B 



WO 99/33016 



PCT/US98/27496 



Trend Test 



Lift* 

+nj — mi 



— H I Head er* ] 

D»ttU ' 



[Clear) 









































































Tren 


d reoort ram data 












PtetfcbtU: |C«M 








T«b97 4,207 
M*r97 2,1*1 
VI 6,983 
M*« 97 2,400 
Jur» 97 7 067 























































































OS t£3 G3 (3S 



FIG. 112A 



WO 99/33016 



PCT/US98/27496 



+4 (Li.fcQ 









Chart 9t Acc»«atf 






IE 


7440 


Misc. Expenses is* 




IP 


(4070 


Misc. Income nf[ 


BA 


1220 


Notes Receivable J: | 


6A 


1620 


untce equipment 


IE 


7110 


Office Expense |[|| 




It 


6020 


Officer vaoes I: : 


BA 


1240 


Other Receivables 


IE 

bl" 


6110 


Payroll Tex Expense I'll; 




2180 


Payroll Tex Payable 




BA 


1520 


Pepeid Fed. Corp. Tex ||| 




IE 

ba"" 


7130 


Poslsoe and Courier Services J || 




1510 


Pre pet d Expense | III 






BA 

Is™ 

IP 


1530 


Prepaid Franchise Tax III 


3900 
5020 


Prior Year s Retained Earnings 1 
Purchase Discount ||.h1 



00 

.00 
-.00 
00 

.00 



1 EHport StE 1 [ Graph KG 1 | Print XP \j Done j 



BL "2360 



4090 
9010" 



It 7140 



IE 7030 [ Telephone 



State Income Tax Expense" 



jE 7220 Taxes - Others 



.!L_...?_!. 5 £..„ T axes - Penaltg 



7350 



11640 



BA ! 1 2 1 0 Trade Acct Receivables 



Tra vel 

Utilities 



t Missing ] [ 



RR 



I 



FIG. 112B 



WO 99/33016 PCT/US98/27496 



IV fa. 




WO 99/33016 



PCT/US98/27496 



Operational 
Management 



Strategic 
Management 



VP 



Mgr. 



I 



Financial 
Legal 



Fire 
wall 



Engineer 



President 



Realistic goals to 



accomplish 
Profit/sales 
Task performance 
Gains/growth 
Bonus based 
Skill based 
Individual/team 
Customer based 



Lawyer 



CPA 



jF 



Digital links backbone for 
Human Resouce Department 



± 



Customer 
Service 



Suggestions 
(ownership) 
Polling 



% of task 
assignment 
List task 



V H V 



Technical 



Purchasing 



Accounting 



Shipping/ 
receiving 



Customer 
Feed back 



Score keeper 
Performance 
Evaluator 
%of 
success/failure 



Education for employee 
Financial data (modified) 

Cash flow, profit, tax, 
sales, returns, past dues, 
credit memos, 
OK to fail. 



Measurement 
factors/parameter 
(criteria based) 
Individual 

Team 
Department 
Company 



Factors direct 
affecting 
sales/profit 



Compensate 
bonus 



Weakest link 
Strongest link 



Long term effect 
Short term effect 



Upstream 
effects 
Downstream 
effects 



Cost 
effect 



FIG.114 



WO 99/33016 



PCT/US98/27496 



Fig. 115 




Fig. 115B 



WO 99/33016 



PCT/US98/27496 



Personal data 


Date 


No. 


Hirino 

1 111 I1IVJ 


Pnmiovee No 


Medical 


S5.No. 


Birth 


Driupr iicwisp 

UllVwl ILvwItwG 


Graduate 


Passport 


Tprminatinn 

1 Gill III luUUli 


Rirth Cprtifiratp 




Phone 

1 1 Iwl Iw 

Panor 




rdycl 

Email address 


Personal 


Family 


Achievement 


Address 
Marriage 


Education 


Chidren 
Persons for 


BS/BA 


emergency 


MS 




PhD 





[ 



Previous Employment data 


Previous Performance 


Date 


Traininq 


Projects 


Job 


Promotion 


Certificates 






UttlllUUUII 


Hinlfima 
UlplUIIld 




Titlp 


Raise 




Source of data 




Cut 








Awards 








Certificates 








Medical leaves 








Vacation 
Personal 








Compensation 








Stock 








Salary 








Awards 








Bonus 








V 








Raises 









Outside Source 



Input to database 
Print, sign and scan 
Application - Resume 
Medical enrollment -W-4 



With signature 



Achievement 



n 



Supply data to search 
for Potential candidates 



Human Resources 



Performance Measurement 

Factual Review 
Responsibility 
Productivity 
Quality 



FIG.115A 



WO 99/33016 PCT/US98/27496 



Patents 




i 



Personal data 


Date 


Na 


Hiring 


Employee No. 


Medical 


S.S. No. 


Birth 


Driver license 


Graduate 


Passport 


Termination 


Birth Certificate 




Phone 




Pager 

Email address 


Personal 


Family 


Achievement 


Address 




Marriage 




Children 


Education 


Persons for 


BS/BA 


emergency 


MS 




PhD 





Effect to downstream 
Effect to upstream 



Employment data 


Date 
Promotion 
Demotion 
Raise 


Trainino 
Certificates 
Diploma 


Cut 

Awards 
Certificates 
Medical leaves 
Vacation 
Personal 


Assets 
Mobile 
-Computer 
•Phone 
•Printer 

v 


Compensation 
Stock 
Salary 
Awards 
Bonus 


Fixed 

Table 
Desk 
Chair 

v 


v 

Raises 


m 



Performance 


Routine 


Assianment 


Time in 


1. Major 


Timeout 


Date_/J_ 


Sick leave 


2. Minor 


Personal leave 


Date_/_/_ 




3. Other 


Regular 
Manual 
Reviews 


Date_M_ 


Projects 



FIG.115B 



WO 99/33016 



PCT/US98/27496 



CD 



< 

CO 



CO 
CO 



O 

CO 



Q 

co 



ill 

CO 



WO 99/33016 



PCT/US98/27496 



•3 
S 



CO 



cO 



"oo 



"S 



CD 

! 



s- 
s. 



<x> 

■s 



CD 



E 8 

CO CD 



DC 



a> a> -S2 

^ jcr -a IS ^ >c 
O CO ci w ^ to 



<2 CO 

.g "CD 

(O « o 

o ^ a 



§ 



co «2 cn 
8 g? S> 

O — I 1 



CO CO 
cO "co CO 

" 8 " 



8 



C_> 

a. 



B s 

fa a> 



^ ^ ^; cj> 



CD 
CO 



CD £2 

a5 LX. 



CD- ^ £ ~ 

C_> CD 



s 

CD 
CO CD 

CO £ 

p 
o 



CD _ 

to 7g .2 

a> cd ^ 

"co to 

a> a> o 

O S " 



"i S q 8 

CO « £ 

iS to S -3* 

O O CO CD 



CD JO 



CO Q_ cO 



CO 



CO 



i§ 1 - 

9> IS no 



8" 



CO 

73 a. "co 



> r **l -s 

c < ir> 

3 OC co' 

.CD 

I CO CO 

i CO 



CO 

o 



< 

CO 



WO 99/33016 



PCT/US98/27496 





5 


A/R 


A/P 




Purchase 


$ 

ca 
co 


CO 
CD 

ca 
CO 


Rec. cr 


Exp. V.cr. 
V.cr. 
C.cr. 
Rec. cr 


Exp. Vcr. 
V.cr. 
C.cr. 
nee cr 


Exp. V.cr. 
V.cr. 


Create date 
Fax 


V. recdate 
VShiD 

Crecdate 
C. ship 

Create date 
Fax 


V. recdate 
V.Ship 

Crecdate 
Cship 

Create date 
Fax 


V. recdate 
Crecdate 
V.Ship Cship 




A/wm ml 

Account 
Payable 
Engineering 


Account 
Receivable 

Sales 
engineering 


Account 
Payable 


Q_ 
CZ 


Received from ven. 
Ship to oust. 
Due date 
Paid date 
Approved 
Scheduled 
Reviewed 

Entry 
Create date 


Create date 
Issue date 


Ven.cr. memo 
Rc/d date 


Freight, Tax 


Total amt, 
Vcost, 
Pcost, 
Freight, 
Tax 


Total cr., 
Sprice, 
Pcost, 
Restock, Tax 


Total ven. cr., 
Pcost, Vcost, 


etc. 


Total Inv #, 
Past duel of 
invoices • 30, 60, 
90 days 


Total Items 
Credit memo 


Total items 
Ven.cr. 




VenJnv. 


CustCr. 


Ven.Cr. 



CD 
<0 



Urn 



WO 99/33016 



PCT/US98/27496 



CO 



CO 
=5 

o 



CD 

"! £ 

Q_ 



CD 

■I 



^ CD 



8 



^ ^ o 



> d o 



CD 
<T3 



^ X 
CD CO 

O 



CD CD 



<X> 



--e -o :e -a 

o CO cp 

^ !> ^ CO £ ^ 



• as 



is JE 

c_> CO o w ^ 

2 ^ o I 



CD CD 

to Q. "c3 

"C3 "F= "C3 



CD 



CD 

X 



CD 
CO 



o 



o 



w 8 ~ € 



o 



o 

(O 



LL 



is 



1 |£ 



J3 



1 1 
§ I- 



CD 

? 
§ 



co 
Q_ 



^ S 3 

■o °2 -g 

13^ 



CD 

CO CD 
CD ^ 



CO 



CD 



CO 

7/5 



T3 



8 _<o 

I-J§ g 



i § 

9 § 



in 

— t co. co 



5 ?5 



g i 

CQ — 

il 



5 



E CD 



i I E 



§5 « "1 « 

c: co a> .a> 



CD 



co 



'8 



I 



WO 99/33016 



PCT/US98/27496 



A/R 




Purchase 
Customer 
Service 


Ship/Rev 
Install/ 

Pnninpprinn 


.s- 85 


Sales 
Rev 


CO 
CD 


Purchase 


Exp. V.cr. 

V.cr. 

C.cr. 
Rec. cr 


Exp. V.cr. 
V.cr. 
C.cr. 
Rec. cr 


Exp. V.cr. 

V.cr. 

C. cr. 
Rec.cr 


Exp. V.cr. 
V.cr. 
C. cr. 

(ICO. Vrl 


V.Ship 
Crecdale 

C.ship 
Create date 
Fax 


V. recdate 
V.Ship 

Crecdate 
C. ship 

Create date 
Fax 


V. recdate 
V.Ship 

Crecdate 
C.ship 

Create date 
Fax 


V. recdate 
V.Ship 

Crecdate 
C.ship 

Create date 


Account 
Receivable 


CSR 

Sales 
Ship/Rev 
Engineering 


Sales 
Account 


Sales 
Account 


C.payment 
Check 
Post 

Approve 


RMAV.rcVd 
RMA V.Ship 
RMAC.rcv'd 

RMAC. snip 


Duration/customer 
Rate of growth/ 
period 


Duration/customer 
Rate of growth/ 
period 


Total amount 


Total RMA 
credit 


Total$ 
Total $ per 

cust. 
% of Avg. of 

margin 


Unclear inv. 

Inv. $ 
Clear inv., % 


CusL Invoices 
C.cr.memo 


Total RMA items 


# of customer 


# of vendor 


CusL Payment 


oc 


Customer 


Vendor 



o 

<0 



g 

LL 



WO 99/33016 PCT/US98/274W 



S2 c= 
J= .5= & 
CO 



8 

73 
CO 



8 



Q> CD 

"S3 .o- *E5 



CD 
"CO 



o CO c_> w S ,7 s 



^3 CO 
GO CO 



CD CD CD CO 4=3 
OJ OB OB "° u. 
"C3 "C3 ~" — ^ 

a> co _ 

o2tt il 



^ n 



CO Q_ 



a) § I 

-t=i ^ .tzi 

^ 19 O 

►S £ 23 



35 

CO 

■g 



CD CD 

i-i 



^ QJ 

ill 



43 " 

. C3 
a cd 



CO 



CD 
CCJ 

ci 

CD 



CD 
CO 

_ *° >5 
CO _CD Co 

CD 

o 



CO £5 



"S 

•cz 
CD 



« « ci 



CD 

"co 



CD 

*CTJ 



CD 

a 43 



cp CO o «« 

c3 . CD . - tt* 

*— i_ C_> CD 



CD C§ 



c3 



111 



O 

UL 



1 



.g .6 
2 is 



o 



WO 99/33016 / PCT/US9M27496 



WO 99/33016 



PCT/US98/27496 



CD 
> 
CD 

CO 

"ca 
o 
CD 



co -£2 o 
c5 § o 



CO CD 



o a> 

CO CO CD 



ca ^ o g 
cz _q r o) o 



co 



CO -— to 



co o 



-2 -g 



CO 

"co 

co 
c 

<: 
8 

c 

CO 



E 
o 
o 



I 



O 
CO 

c= 

CO 



a 8 

CO 



O ^ 

•8 ^ ™ 

"o -fe -g 

co = co 

o -Q to 

8 c ~ - 



CO 
CO 



_ O Q) W 

~ E 



CO c co 

CD 



< -a co 
t= co 

8 





"co P 






inancial An 
Algorithi 




U- 



co 

Oi 



CO 

"co 

CO 



CO 



CO ^ CO .<fi 



CO 
CD C 

E « 

CO CD 

w E 

CD 

o iS 

c CO 
CO — - 

cr .eg 

rr o 



CO 



CO 
cz 

co ^ 



CD 



CD 



-= a> £ 



CD S 
CO S 
CO ™ 
CO 



CO .2 



co o 



co 



co co 



co 

CD 



o CZ 
CO 

c ex. 
2 E 
CO o 

a- O 



£ 8 

o -g 

.co c= 

> co 

o ca 



^- CM CO 



J2 

o 

CD CO 
CD 2 ^ 

E ac 

co g c 

CO E CD 

< c w 
i cp CO 

(/)'«< 

n ^ 
lit 

Q CD LU 
in co s 



CD 
CD 



CD 
O 

£= 

co 
E 

o jg 
| & 
« Q 

Z3 

O 
CO 



Goal Intelligent 
Incomplete work 
protization 


CD 

JC 

O 




CD 

E 
f= 













o 

CO 



o 

o 
E 

CO 





CD 




Dal 


hie\ 




Ac 


Qty 




CD 


Goal 


Dal 






c 


Date 


Task 
assignn 
proje 




s 




< 



O 
U. 



WO 99/33016 



PCT/US98/27496 





Other 




ictual 


Time 












Qty. 





Norm 


Other 




Time 










Qty. 





Q- 

E 
o 
o 



I 

o. 
E 
o 
O 



J 



CD CO 

O CD 

^ 12 

O =3 

£ 2 

E cr> 

o o 

iS o 

CO o_ 



<D 

O) CD 



2 CD 

H- E 

.O CD 

^5 E 

CD d. 

CL r= 

CO E 



CD C 

"2 co 

co c .Q 

u £ y) 

a> 55 

F o CD 



O CO 



o 













CD 


CO 

m 


vem 




o 


Wor 


Imp 


CO 





AB|dsia 



o *w 

CD CD 

aS ™ 

CO 13 
"to 

& "S 

CD S 

til 

o 
O 



CD 



T3 
CD 



CD CO 



CO 



O 
CO 



CO 



o 
DC 



-° co a> o co'ca^ S e 



g> .?= CD 

S g co I 

^ c ^ eg 

CO co "o> o 

— — CO 



CD C 0> C § 

<£ 2 S _o- 4= cq 



7= o S£ 00 

i- o o) □ c 
<C Q- — 



f E S 
co <» a> 





8 


















CD 








-S 


O 


list 


les 




o 


$ 


CO 




CD 


ID 








1 Se 


E 








o 









I 



o 
_o 
<c 

o 

CO 
CO 

o 
E 
o 
O 

CD 
O 

co 
o 

CO 
CO 
CO 

O 

"co 
.o 

o 
± 



co a. 
cz 



£ is 

LL» CO 
O 



*o 

CD 
Q 

co Ot 

CD 'to 
CD CO 

1^ 

Q. CO 

.co 



CD 



(3 
Li. 



WO 99/33016 



PCT/US98/27496 



o 



CO 

as 

CD 



CD 



CD 
CD 

o 
E 



CD 

E 

CD 



co 
■a 
c 

CD 
CX 
CD 

c= 



CD 

C F= -E 

E _ 2 

CD •— CD 

S CL O CO 

S x « □ iS 
eg a, td -g — 

So as 
fcz - o 
CO 



co 



t — ' 

g o 1 1 s. | 

m o g sc.. 
-a cp =3 a> fc -g 

- $ 3 « ^ •§ 

i 



S3 a> 



a> cd 
,co "O 



I -g 

Q> "CO 

5 .a 

CO >T 

co S 

CD CO 

E lc 

"O cz 
cd 

co co 

CO 

CO co 



-=l CD 

eg s 

3 c co 

o co "co 
F > 

U- E To 

E £ ^ 

O CD 



_ CD 

^ E 

.CO O) 
'to 

CO 
CO 



CD 
CO 



5= co 

O =3 



CD 

o 



co "a -°. co co "o 



CO 



CO CD 

=>• to 

CO 



3) 5 £ 
^ ^ o_ Jo o e 

as -co g 



CO 

ZD 

o o 
co g 

8 52 

CO 



co 



o 

CD 



CD 

TD ~B 

CD -o 

O" CD 
t_ CO r- 

Q_ -a o 

CO 



IS 



ll 



CD 

E 
CO 



oes cd 



—J co 



W I— 

□l CD 
to CO 



I 



I 



CO 

1 

o 

"8 



CD 
CD 



Q 



LU 



CO 



8 



CO 

c 

.2 

"S3 
o 

'8 

CO 

o 
"co* 



& 

o c ffi 

_2 o o 



CO 

o > 
CO CD 



CD 
CO 

o 



to a> 

O) CO 



05 , 

8 2 



+ 73 



CO S "> °cJ 

CD "7^5 t-J 

(1) I? □ ^ 

C O C ? 

O — •*= a. > > 



I 
I 



CD 

E 



<t o a 



CD 

E . ^\^\ . CD CO 

P= CD <JS|0 DC CO 



o 

52 

CL 



E 

CO 

£ 
"55 
c 

§ 

-a 



CO 



a 3 



o 



o 

LL 



o 

< 

E 



Ok 
Oi 



o 

TO 

Z5 

_ "O 
CO CD 

E 

a a i= 

^ cvi co 



CD 

[§ <*> 

S co 
n eg 

CO -Q 

co eg 

g "co _ 

CO o ^ 

its 

£ co & 

^ CD CD 
CD 

CD *~ >-> 

> .E .o 

l "i i 

~| s 



■s 

CO 



o 

^ o 

. . CD , 

.E cd 

CO o 

■o a c 

CO t— j co 

^ to 

£ -o .£ 

CD 

O CO 

"to CO » 

i55 ■ 



5 5 



CD 

o 

c: 

CO 

c: 

CD 



CO 



^ E 



o 

— CO ^ 
CD 

E 8 

Q CD 

co r: 

B 1 



o 



ts 8 



CO 
CO 
CD 



o _S 



o K § ^ o 
"o <C _o o ^ 
O ll o 5 o 



^— OvJ 



CO 



WO 99/33016 PCT/US98/27496 



Organization level 

* Department 

Group 
Employee 



Department 
* Sales 
Maketing 
Engineering 
Customer Service 
Purchasing 



Group 
Calif, group 
N.W. Group 
N.Y group 
Special Acct. group 
* Large Acct. group 
Commercial group 



Employee 

* John Doe 
Robert Doe 



FIG.118 



WO 99/33016 



PCT/US98/27496 



UL 



< 




O 


CD 








Oi 
















U- 


d) 
il 


iZ 



WO 99/33016 



HA),- 



PCT/US98/27496 



CO 

co 

I 

CO 
"CO 



Q_ 
CD 

CO 



CO 
CO 

"CO 



o 

'X3 
CO 

"co 
p 

~c3 

CD 



i 

co 



CD 

-cr 

CO 



"S 

CD 



CD 



DD 



CO 

-8 

SB 



s 



CD 

c55 i3 



CD 

<3 



Downstream 


Customer 
Service 


"8 
■§ 

=□ 


Purchasing 
Receiving 


Upstream 


Customer 


Customer 


Inside Sales 


Profitability (C) 


Gross Margin 


NA 


Commission 

earned 
Gross margin 


Restocking fee 
Partial vendor 
crmemo 


m. 


Accounting 
C.Cr. memo (B2) 


NA 


# of invoice 
/crmemo 


# RMA return for 
credit 

# RMA return for 
exchange 


Quali 


Time period (B1) 


POdate 
Quote date 


Create date 
Review date 


Create date 
Cust. rec'd date 




% profit/period 
(A3) 








Productivity (A) 


$/period(A2) 










Qty/period (A1) 










Measuring 
Parameter 


Quotes 


CO 





< 



u. 



WO 99/33016 , / PCT/US98/27496 




I 



WO 99733016 



PCT/US98/27496 























































A/B/C 




A/B/C 


A/B/C 


A/B/C 




A/B/C 




A/B/C 


A/B/C 


A/B/C 


o 


A/B/C 


o 


A/B/C 


A/B/C 


A/B/C 




A/B/C 


A/B/C 


A/B/C 


A/B/C 


Measuring 
Parameter 


Quotes 


1 





CD 
.22 

CD 
CO 



O 



O 
u. 



WO 99/33016 PCT/US98/27496 



o 

CM 
LL 



< 


CD 


o 


o 


CM 


CM 










ll 


Ll 



WO 99/33016 



PCT/US98/27496 



<u o 

o M 



CM 
CO 



CD 
CO 

3* 



CD 
CO 



CD 
o 

CM 

d 



WO 99/33016 / PCT/US98/27496 



Fig. 121 



Fig. 121 A 



Fig.121B 



Fig.121C 



WO 99/33016 



PCT/US98/27496 



Invoice -pay -yen /terms In -En -Rv MVS /qtg - cost PO -bil 



1975912-01 
flTT 

> 

iCmpLnd 



[5/10/93 t . 

N30l 3/22/93 



M93-0085 

98.80 



8 
97 



P 12,605.96 L: 959.00 9/1 



1171613-01 


17/1/93 


I 


ilTT 


loo/oo/oo 




ICmpLnd 


N30I7/1/93 


F 




1178411-01 


17/5/93 


r 


IlTT 


ioo/oo/oo 




iCmpLnd 


N30 17/6/93 


F 




1171612-01 


15/19/93 


f 


•ITT 


[00/00/00 




ICmpLnd 


N30i5/19/93 


F 


1 t 


1171611-01 


I 4/22/93 




IlTT 


loo/oo/oo 




ICmpLnd 


N30 lOO/OO/OO 


If 


iTESTm 


2905011-01 


14/14/93 


\t 


IlTT 


loo/oo/oo 




ICmpLnd 


N30I4/14/93 






4415611-02 


14/2/93 


r 


IlTT 100/00/00 




ICmpLnd 


N30 14/2/93 




i 



Options! (Exclusive! r 1 



Invoices: 0 


Invoice * 


PO 


4415611-02 






»— . 
























I 




3 

......................... ^ 








j 






l< "(J 


Add Delete 



Dupeti 



Q Problems 
□ Vendor RMA 




+ 

JLJ 



Sort 



Sets Find Nev Re< 



FIG. 121A 



WO 99/33016 



PCT/US98/27496 



Uen_lnuoices: 7 of 27234 (Sales-MU 



muu invuit_e> 



Payee 


Vendor 


i RX 


Inv Date j Total billed 


iTax 


















| 










i 




















j 






An Invoice with this invoice number is already 
entered for this payee! 



OK 



Done 



sords Return Rel, 



move Pre 



Historical 



FIG. 121B 



WO 99/33016 , PCT/US98/27496 



1 

1 

; 

L 


[fteviev Status 


Date - Pau - Von 




i 






i 

! 

t 
l 

j- 






{ Freight i T« 








H i0o-9^n IN' 


X 








i 


i 














,: 








MM! 






































Cancel 






ePa,d Act Distribution ] 


i on [ Set Partners Acts ] 



FIG. 121C 



WO 99/33016 



PCT/US98/27496 



Fig. 122 



Fig.122A 



Fig.122B 



Fig.122C 



WO 99/3301 6 PCT/US98/27496 



I 





Invoice -pay -ven /terms (in -En -Ry 


r|MVS /qty - cost PO -billed 


15/17/98 

RXiACE 16/12/98 


invoices: 0 


I ACE N30!00/b6/6c 


Invoice * 


PO 


Payee 






1234567 
1234567 




ITT 
















i 
























\ ! 


: : 








~ „.„. 






: 








: ; 








i : 
; „.„„„ w £ 
















: 
: 








: j 








• : 
















i 
















! ! 

i...„„...„ „ 


















+m -m 

Add Delete 1 


2Sfi 0ption$|(5Ja^?) c 

PUPe3 □ Vendor RM A * 



FIG. 122A 



WO 99/33016 



PCT/US98/27496 



|Hext payment I Status-problem |RM A -Vcr edit [Disc-Dt-$-Ls |Cust lr 

Add Invoices 



I Vendor 



ITT 



RX j Inv Date j Total billed 



112/21/97 j 10 # 000.00 



Tax 




You have already entered this invoice on this 
batch. 



OK 



Done i 



FIG. 122B 



WO 99/33016 



PCT/US98/27496 



nv Stats Reviev Status 



reiqht 



T« 



N30 



N3 



|;tiiij:iii:|:|::ii 




Cancel 



[rx]] 



Date 



Pag - 



6/16/98-5,000.00- 



t Distribution 



Partners Acts 



FIG. 122C 



WO 99/33016 



PCT/US98/27496 



Fig. 123 



Fig.123A 



Fig.123B 



Fig.123C 



WO 99/33016 



PCT/US98/27496 





Invoice -pay -ven /terms 


In -En -RvjliVS /qty - cost PO -billed 


1975912-01 


5/10/93 f 




!ITT 


OO/OO/OC 


Invoices: 0 


[CmpLnd N30 


3/22/93 




Invoice * 


P0 i Payee 


1171613-01 17/1/93 


4415611-02 




[ITT ioo/oo/oc 




e 


iCmpLnd N30 17/1/93 












1178411-01 17/5/93 




i 


i!T.T . loo/oo/oc 






[CmpLnd N30 17/6/93 












1171612-01 15/19/93 






HIT. ioo/oo/oc 






ICmpLnd N30!5/19/93 








1171611-01 14/22/93 




i 






[!TT loo/oo/oc 






[CmpLnd N30 1 00 / 00 /OC 


•TESTING 






2905011-01 14/14/93 












[CmpLnd N30 14/ 14/93 






; * "™ ■ 






4415611-02 14/2/93 




iiTT iob/bo/oc 


Add Delete 


SSfi 0pti0ns| (Exclusive) rl 
l±2Sj □ Problems | 
DuDea □ Vendor RMA *■ 



FIG. 123A 



WO 99/3301 6 PCT/US98/27496 



jMext payment [Status- problem jRMA -Vcredit |Pisc-Dt-j-Ls |cust lr 

Add Invoices 





Vendor 


RX 


Inv Date i Total billed 


! Tax IF 








t 


















































"** - :-*• - 

1 1 










L i 




j 


i i 






An Invoice with this invoice number is already 
4 entered for this payee! 







Done 



FIG. 123B 



WO 99/33016 



PCT/US98/27496 



w Stats | Re vie v Status 



Date 



Pay 



reight j Tc 



N2<> 



:t::j:;i ::! :•::::!, 




US 



Cancel 



t Distribution 



Partners Acts 



FIG. 123C 



WO 99/3301 6 PCT/US98/27496 



Fig 124 



Fig. 124A 


Fig. 124C 


Fig. 124D 


Fig. 124B 





WO 99/33016 



PCT/US98/27496 



r 3 File 



Get all not paid 
Get not reconciled 
Get Reconciled 

Reconcile with credit 

Pre-Approve- 
Get Pre-Approve 
Remove Pre-Approve 

APPROVE... 
Get approved 

Schedule payments 
Schedule pre-paid payments 

Get discount paymnents 
Schedule discount payments 

Close selection... 
HOLD selection... 
Get Hold 



ga Activities Help 



[Ver 



There are i 



FIG. 124A 



WO 99/33016 



PCT/US98/27496 



Close selection... 
HOLD selection... 
Get Hold 

Reset status back 1... 

Edit terms/payment/vouchers., 

Integrity check 



Mark ready for review 

Get ready to review 
Mark reviewed 
Get reviewed 

Get Tracking 
Mark for Tracking 
Remove tracking 
Tracking notes 

Current status/Review status 

Cash flow analysis 
AP Processing 

Show Invoice Detail 




Temporary notes 



CD <5 i 



(PupesD 



Update invoice 



New Records Return Rela 



FIG. 124B 



WO 99/33016 



PCT/US98/27496 



Invoices: 7 of 27234 (Sales-MWS) j 



o selected records for: Ven_lnvoices 




m £> 

elatedSwitch QuickSwitch 


Total Billed 
Need to pay 







FIG. 124C 



WO 99/33016 PCT/US98/27496 









move Prepaid ] £ Act Distribution J 




historical on (^Set Partners Acts ] 











FIG. 124D 



WO 99/33016 



Fig 125 



PCT/US98/27496 



Fig. 125A 


Fig. 125B 


Fig. 125C 


Fig. 125D 





WO 99/33016 



PCT/US98/27496 




r ^ File Edit Enter Select Reports Megj j 



Get all not paid 
Get not reconciled 
Get Reconciled 

Reconcile with credit 

Pre-Approve... 
Get Pre-Approve 
Remove Pre-Approve 

APPROVE... 
Get approved 

Schedule payments 
Schedule pre-paid payments 

Get discount paymnents 
Schedule discount payments 

Close selection... 
HOLD selection... 
Get Hold 

Reset status back 1... 



m 



Edit terms/payment /vouchers... 



Punea 



Integrity check 



Temporary notes 



FIG. 125A 



WO 99/33016 , PCT/US98/27496 




a Activities Help 




Uen_lnuoices: 0 of 26071 (Sales-Mil) 



i 

There are no selected records for: Ven_ Invoice 




FIG. 125B 



i 



WO 99/3301 6 PCT/US98/27496 



3M/43 



4:07 P^ 




es 



Remove PrePaid 



[ Act Distribution ) 



Historical On 



Set Partners Acts J 



FIG. 125C 



WO 99/3301 6 , PCT/US98/27496 




Update invoice 



Mark ready for revrew 

Get ready to review 
Mark reviewed 
Get reviewed 



Get Tracking 
Mark for Tracking 
Remove tracking 
Tracking notes 



FIG. 125D 



WO 99/33016 PCT/US98/27496 



33 ^fcr 



Fig 126 



Fig. 126A 



Fig. 126C 



Fig. 126D 



Fig. 126B 



WO 99/33016 



PCT/US98/27496 



Options 

Quick Invoice Lookup 

Cust Invoice Summary 
Print Selection 
Co mm Report 



/an 




FIG. 126A 



WO 99/33016 



PCT/US98/27496 



Get AR Report selection 
Get Not Issued 
Get not paid 
Get no charge 
Get pre-paid 

Close - No charge 

Split Invoice 

Join 2 Invoices 

Issue Invoices 



FIG. 126B 



PCTAJS98/27496 




d <^ » 




New Records Return ReUtedSwitch QuickSwitch 



FIG. 126C 



WO 99/33016 



PCT/US98/27496 



(Sales-MVYS) 




for: Cust— Invoices 




Collections 



Notes 



No payments 



Partial pay 



De- Issue 



Sales Adj 



Historical On 



Post 



c 



c 



Recalc 



Totals 



a 



FIG. 126D 



^ 

WO 99/33016 PCT/US98/27496 

Fig 127 



Fig. 127A 


Fig. 127B 


Fig. 127D 




Fig. 127C 





WO 99/33016 



PCT/US98/27496 





IE 



Sort Sets 1 Searches | 



FIG. 127A 



WO 99/33016 



PCT/US98/27496 



Items Sold: 0 of 44942 (Sales-MWl 



There are no selected records for: Items Sold 




Expedite / Availability 

Customer Notes... 
CSR Notes... 



<p m £> 

Return RelatedSvitch QuickSvitch 


Options 

Quick MVS* Lookup... 
Add MVS to Fast Order... 





















FIG. 127B 



WO 99/33016 



PCI7US98/27496 



Status (restricted)... 

Expand to all items sold 
Remove shipped 
Check selection again 
Update MVSs... 

Clear updates 

Tech Expedite 
Clear Tech Expedite 

Get InHouse not rcvd 
Receive InHouse 

Get Installation not rcvd 
Receive Installation 



FIG. 127C 




WO 99/3301 6 PCT/US98/27496 



WO 99/33016 PCT/US98/27496 

Fig 128 



Fig. 128A 


Fig. 128B 


Fig. 128D 




Fig. 128C 






FIG. 128A 



WO 99/33016 



PCT/US98/27496 



lies Records: 0 of 26680 (Sales-MUli 



no selected records for: Sales Records 




RelatedSvitch QuickSvitch 



Options 

Quick MVS* Lookup.,. 
Quick Quote* Lookup... 
Quick PO/RFQ/PID/PRN LU/Conf.. 

PurchChecks... 
Real World.. 

Update MVSs... 

Expedite / Availability /Pur ch 

Urgent... 
Not Urgent... 

Daily PO Confirmation... 
Get Quotes... 

Print Quote Confirmation... 



FIG. 128B 



WO 99/33016 PCT7US98/27496 



Apple Status... 

Quotes requiring REVIEW 
Cancel REVIEW 

Get purchasing records... 
Print Purchase summary... 

Clear updates 

Lock 

Unlock 

Get Unlocked 

Change TPO to Real PO 
Get Temporary PCs 

Get Web Quotes 
Get PPL Quotes 

Get/Create PIDS 

Delete protect selection 
Remove delete protection 

Mark selection for deletion 
Undelete selection 

Edit Credit Card Info... 



FIG. 128C 



WO 99/33016 PCT/US98/27496 




FIG. 128D 



WO 99/33016 



3X// 



PCT/US98/27496 



Knowledge 
Base 



user input of non-functionality 



Process Dispaly 



Move item to next stage action manipula- 
tion parameters, 
e.g. RMA-approve, cancel 
cust. cr. memo 
cust. N/A etc. 
V. Inv.-mark for approval 
Cust. I nv. -create aging 
Expedite - reason for not rcv'd 



Data Input Dispaly 

Fig.59E1-E9 

e.g. (1) Vendor Invoice - input intelligence 
(2) PSRI - receiving 

only order items are allowed to be 
received 



user input of non-functionality , 



System Analysis & 
Design 



Range : best to worst 
possible outcome 



Fig. 129 



WO 99/33016 PCT/US98/27496 



FIG. 131 



FIG. 131 A 



FIG. 131 B 



WO 99/33016 



3rt 



PCT/US98/27496 



is 



CO 

o 




I 



5 $ 
2 a! 



i s Si 



23 

o w 



CD 
CO 

d 

LL 



WO 99/33016 , PCT/US98/27496 



FIG.132 



FIG. 132 A 



FIG. 132 B 



WO 99/33016 , PCT/US98/27496 




WO 99/33016 PCT/US98/27496 



FIG. 135 



FIG. 135 A 



FIG. 135 B 



FIG. 135 C 



FIG. 135 D 



FIG. 135 E 



WO 99/33016 PCT/US98/27496 



3^/0 




WO 99/3301 6 PCT/US98/27496 

*bh far 




WO 99/33016 



PCT/US98/27496 



o 
o 



o 
cn 



o 

i 

CM 
CM 




x8 

iil|S§ 



T 

e'- 
en 
vo 
vO 
cn 



o 
m 



W 
ui 

CO 

o 



Ov 

i 

O 
cn 




o 
cn 



8 
9 

CO 



d 

Q 



o 

cn 



d 



o 
cn 



cn 

I 



O 
cn 



oo 
o 

s 



8 




Q 



o 

cn 




m 

CO 



(3 



d 

Q 



WO 99/33016 



PCT/US98/27496 




WO 99/33016 



PCT/US98/27496 



CO 

3 

4-* 

4i 
U 

o 

CO 



CO 

H 



4fc 
60 



2 

H 
u 

2 

O 



0< 

£ 



^ ^^^^^ 
2 © © © © © © a> 

a O m n O i- 

g fH VH *N VH *4 *H « 

goooooo 
«> 2 2 2 2 # ° A 

3§§§i§§ * 

o o o © © © e*i 
&<©©©©©©g 

HHlHHHHZ 

j 5 

« w 

W0O0O0O00QO0O© 
ft. iJ J nJ J J N-) _ 

-< < «< < ^ < 9 

H cu ft, ft, ft, CU ft, 
^OOOOOOj 

auuuuuu u 
S a w w w w w ^ 

£ CO W W CO w w 

fccocococococoH 

H co 
> 

W 
CO 



1 



* 

M 
a « 

cox 



<£> 
CO 



WO 99/33016 



PCT/US98/27496 




WO 99/33016 PCT/US98/27496 



FIG. 139 



FIG. 139 A 



FIG. 139 B 



FIG. 139 C 



FIG. 139 D 



WO 99/3301 6 PCT/US98/27496 



On 



o 



w 
u 

O 

O 

H 
W 
Z 

< 

o 
w 



8 



oo On 
O CN 

if. 
§• 

CO * 

» oo 

3 2 



S2 OO 

E o 

O rr 

2a 

m o 

00 -c 





3e2 



SO 



S3 
1 

s 



41 

a v 



u 



B 
O 



Q 



*3 

55 



s 

p 



IS 



O 

o 



CO 



O 

5 



8 

SO 



a 



8 



vo 
oo 

ON 

*n 



CM 
VO 



CO 



CN 

vo 



O 

»n 
od 
\o 
oo 



CN 
ON 

<s 

O0 



m 

<N 

m 
CN 



CN 
Ox 
CN 
OO 



8 

i 

O 

m 
v> 
m 
m 
m 



6 



is 

o o 
u S 



O) 
CO 



C3 



WO 99/33016 



PCT/US98/27496 



18,416.84 


212,865.12 


27,556.78 


| 87,633.00| 


oo 
»o 

lO 

v\ 
en 


| 2.300.60| 


44,904.09 


ON 

8 


11,678.10 


10,666.44 


3,137.16| 


57,881.94 


to 

»— 1 

ON 

en 


| ■ 

I 


s 


OO 

oo 


13,778.39 


| 1, 460.55| 


888.87 


| 1, 150.30| 


583.17 


1,011.39 


1,946.35 


1,777.74 


522.86| 


1,702.41 


652.54 


i 


179750-001 


241700-001 


273350-005 


|169470-B21 | 


298047-B21 


|333555-B21 | 


272577-001 


313706-B21 


313756-B21 


3O4100-B21 


|224206-001 | 


295242-B21 


225484-001 




PROLIANT 3000R 6/333 P2-333 512K 64MB 
MODEL 1 


PROLIANT 6500 6/200 1 28MB M 1 -5 1 2K NOHD RM 
FS 16XCD 


PROLIANT 7000 6/200-512: MODEL 1S-128 (128 
MB) 


|6/200 5 1 2K PROC OPT KIT PROLIANT 6500 7000 | 


6/300 PENTIUM II 512K PROCESSOR OPTION 
KIT 


(PROLIANT 3000 6/333 512K UPGRADE KIT 


4.3GB PLUGGABLE W/ULTRA LOIN 7200RPM 
SCSI-3 HD 


9.1GB PLUGGABLE W/ULTRA LOIN SCSI-3 
7200RPM HD 


18.20GB PLUGGABLE WIDE-ULTRA SCSI3 
DRIVE (1.6") 


PROLIANT STORAGE SYS /Ul RM SINGLE BUS 
ULTRAWIDE 


REDUN P/S KIT PROLIANT STORAGE/F | 


SMART-2DH PCI 2CH ARRAY CONTROLLER 
W/1 6MB CACHE 


128MB EDO MEM EXPANSION KIT (1 X 128MB, 
60 NS) 


1 

! 
1 

i 

I 1 
I 




oo 


CM 


8 


-bl- 


CM 


r- 


g 


VO 


VO 


VO 




VO 


I 
i 


each 




each 




each 


(each | 






each 








each 


\ 1 




oo 




S 




CS 






VO 


VO 


SO 


en 


VO 





WO 99/33016 PCT/US98/27496 




o 

CO 



u. 



WO 99/33016 



PCT/US98/27496 




CO 



WO 99/33016 



PCT/US98/27496 




WO 99/33016 PCTAJS98/27496 



FIG. 141 



FIG. 141 A 


FIG. 141B 


FIG. 141 C 


FIG. 141 D 



WO 99/33016 



PCT/US98/27496 



o 
in 



! -II 



0* 
O 

o 
> 

e 

i 

o 
ft. 



o. 



to: 
id: 

CM. 

w: 

5; 
O 



to; 
w: 
ov 
in: 



> 

o 

k. 

£ 
e 

M 
3 
U 



: vx>: 
ov 

; cm: 
> i • 

:8: 

: ro: 
: cm: 



; io 
* in 
: cm 
: ro 

5 
o 

V0 



O. 

o; 

5: 
o 

fo 



ro: 

oo: 
cm: 
i • 
co: 
ov 
£: 



K 
C 

c 
tf 



: no: 

. 0\- 

: cm: 
- i . 
: o: 
. cm. 
: r*: 



; cm 
: w 

o 
o 

ro 

V0 



K: 
«■ 

o: 



<: 



o: 
*: 



E 
o 

9 

01 



I 

£ 

Of 

I 

0> 
* 

a 

i 

4i 
O 
*m 
O 
> 

a 



a: 



: ro 

' 00 

: on 

• CM 

: i 
: o 
: cm 

: ^ 
: /~\ 

• ro 



o: 

fa: 
•j: 
<: 

o: 

u. : 

o; 

*: 
E: 
<• 
oa- 



st: 

5' 



■1 



: m 
• <r 
: cn 

c 

: I s 



01 

o 



, L 

L2 

N 



o: 



ac: 

o: 

K: 

3- 



: ro 

• CD 

: on 

: <J* 
: o 
: n 



> 

Co 



o: 
fc: 

*! 
o: 

u : 
o: 

*: 
ac: 
<• 

CQf 

ac: 
2 

D 



X 



CL 

X 



: in 



C 



. 00' 

: ov 



O: 



: o: 
: ro: 
: z: 



; ov 



: ov 



a. 
x 



*: 
i.: 

o* 

fd?' 
: z- 



; oo: 



, <M- 



: ro 

• CO 

: on 

• CM 

; i 

: o 
: cm 



Z: 



<: 

o: 

o: 

si 

<: 

oo : 

z: 

o: 

Z; 
3* 



: ro 

• CO 

: 0% 

■ CM 

: i 
. o 
: cm 



: w 

: CM 



a- 



<: 

u: 
u ; 
o: 

*: 
z : 
<• 



< 

d 
u. 



s 

: ca 

CM 

: i 
: o 
: cm 



co: 
W: 



• co- 

; on: 



: oo: 

■ ON- 



c 

: 

. < 



\0: 



CL 



WO 99/33016 PCTAJS98/27496 



TWA: 



iiini 
151 



mil 



L 

U 



r 

u 

I 

X 
H 

I 



ro: 
od : 

o: 



i 

0) 

"5 
o 

ON 
SO 



< 



: o: 



: in: 
: 9: 
in: 



in 
ro 
on 
a; m 



if 



in 



5-: 



ffl 



g 

u. 



WO 99/33016 PCT/US98/27496 




WO 99/33016 



PCT/US98/27496 




WO 99/33016 . PCT/US98/27496 



FIG.142 



FIG. 142 A 


FIG. 142 B 


FIG. 142 C 


FIG. 142 D 



WO 99/33016 



PCT/US98/27496 



o 

in 



J 













O 


m: 
in; 








e 


cm: 










w: 












IT) 








8= 
o* 


p 






o 




in 






a. 




















1! 










*■» 










o 










H 

t 


o: 










*■* 

o : 










oo: 










cm: 


o 






W 


i . 
oo: 






> 

r 


E: 


o 




§ 










Od 






tn 
in 

CM 


1 


L 








i 






SO 






« 

E 
e 




OA 
CM 
1 


I 








o 

CM 

r- 


vO 


3 


U 




/—\ 






» 




ro 

CM 




ON 




<: 










K* 






CM 










o\ 




o. 
















*\ 














< 






$ 




w 




' *c 

: c 


c 




It 




Q_ 




O 




: w 

• 00 


& 








: ca 






X 




■ CM 




* 

E 
e 
+* 

IA 


< 

OQ 




i 

: o 
: <M 




o 


a* 

"55 


: ^ 

: 

: 




Cu: 


r 


u 
o 


: cm 

■ 'W 








o 






* 














z 
























% 


E 








co 


L 










ti 










H 










1 

If 




00 


: £ 




Da 




<r» 
\ 


• D 

: *° 

: c 


Or 


l 




in 






•v 






• *o 




o 


M 






X 


► 

e 


1712 




- < 





CM 



CM 



CM 

! S 
d 



WO 99/33016 PCT/US98/27496 



Ullll 

13 



E 
E 

9 



< 

£ 
a 

i 

x 

T 



"5 
r- 
so 



CO 

o: 



o: 



: o: 

: 



9 
4 



: in: 



a. «N 
o: in 



s 
a 

.a 
•I 



N 

4 



I 

i 

2 



m 

CM 



u. 



in: 



in: 



to: 
in; 



\0- 

ro: 

si 



<7< 
<■ 



: o: 

: 

: w": 



o: 



. o- 

: ri: 
: ^: 
: K)J 



: o: 
: w: 



in': 
tn: 



JELL 



WO 99/33016 



PCT/US98/27496 



CM- 
GO ; 

o; 
°: 
S: 



to: 

^: 
o- 

: in: 



w: 

»: 
n: 
i 

«: 

r: 



: so: 



; o: 
: cm: 



: w: 
: ?J: 



a- 

o: 



<: 

u: 



o: 
*: 



<■ 
tt : 



o: 
zj 

3- 






00 



ca: 
o: 



3 
O 

*0 



3 
O 



C 

o 



"3 
o 



in 

g so 
k. «- 

u 



ro 



Ol+S 1 |09 



SO 0* 
^ CO 

ID 



to o 

O W 



ST 

w * 



KJ 
N 

ro 




o 

CM 



o 

E 



WO 99/33016 PCT/US98/27496 



► Is 



IE 



o 
e 



c 
a 

(A 

L 

ft 

E 
o 

9 

o 



: ■*: 
: cm: 



in* 



: in: 
: ^: 
: o: 
■ in: 



e 
o 

3 
I 

e 
X 



ft 



ft 



o 
ft 



© 



9 



9 
O 



c 
E 

05 
Q. 



01 

£ 



0) 
£1 
(J 
1» 
CD 
0) 



1. 

00 

a 



3 



c 

09 

u 



o 

E 

at 

E 



0) 
u 
o 

u 

o 

c 

03 

E 
a) 
u 



II 
HI 

£ E E 
« * 

£ £ £ 



c 
o 

c 



3 3 3 5° 



o 
u 

TO 



3 
O 



a) a) a> 

E E E 

0) 0J 0) 

u u u 

09 CO 00 

a a a 

0) cu 0) 

QC DC QC 



2 « 

i= » 

2 g 

X3 U 

£ 5 

Q. U 



"I IT 



vD 

cn 

CM 

e o 
us r- 

5 « 



0. 
e 

3 4* 

O .c 

O 
« V. 
< ~ 



e 

* o 

l« 

S 

e < 

L U 

? CO 

5 c 



CM 



511 



WO 99/33016 



PCT/US98/27496 



FIG. 143 



FIG. 143 A 


FIG. 143 B 


FIG. 143 C 


FIG. 143 D 



WO 99/33016 PCT/US98/27496 



O 

m 



0) 
u 



=9 



in: 
R: 

K); 

O; 
O 

ro: 



in: 
P : 
in- 
*r: 



to: 
in; 
<n: 
ro: 

o 
o 

ro: 
no: 



in: 
ro: 
ov 
in: 



o 



o 
a. 

€> 

E 
o 

9 
O 



. <r». 

: cm: 
• i » 
: o: 
: cm: 
: r^: 

: ro: 

: cm: 



ac: 
at* 
o: 
£: 
3: 
<: 
u: 



i 

9 

*M 
Ox 



: so: 

. OV 

: cm: 
- i . 
: o: 
: cm: 



: tn 
in 

: cm 
: w 

o 
o 

ro 

SO 



a 



: ro: 



4J 
U 
OJ 



TTPiiT 



2 w 
o 

£ 



1 



I O £ * W T> 

1.2 * * I: r= 

-El. 2 

i A 5 X ^ c 



It 

o o 
v- a. 



* O X * *S O O 
IUDuu.JEa.fl. 



i. 
if 

E 
e 

9 
U 



*: 
*: 
<■ 



: w 

• oo 

: ov 

• CM 
I 

O 
CM 

r- 
$ 



<: 

a: 



1 



0\ 



x: 
SB: 
<• 

ac: 

o: 



: ro 
• oo 
: <n 
■ CM 
; i 
: o 
; cm 
: r- 
/-\ 
ro 

CM 



CM 
9\ 



f 

E 

L 

if 



(0 



ft 

o 

O 
► 



• 00 • 



: in: 



rat 

:5: 



• 00< 

: on: 



f 

0- 



I 



CM 



K: 

a: 
o: 



<: 

o: 



o: 
*: 



<• 



9* 



CO 



a 

EE 



: ro 

• oo 
: on 

• CM 

: o 
: n 
: r- 



• CM 



: oo: 



> CM* 



£ 

o 

1 



WO 99/33016 PCTAJS98/27496 




WO 99/33016 



PCT/US98/27496 



?! Si 



. \f} : 





3 
O 



3 
O 



e 
o 

IP 
w 

q5 

o 
+-» 

>. 
"5. 

□ 



ID 
N 

^ 2 
to 

o 



^ in 



oi+1 



^ 00 
W CO 



52 

< 

O 



o' 

0* 



10 

m 

N 

w 



CO 



C5 

LL 



WO 99/33016 PCT/US98/27496 




WO 99/33016 



PCT/US98/27496 



RG. 144 



FIG. 144 A 


FIG. 144 B 


FIG. 144 C 


FIG. 144 D 



WO 99/33016 



PCT/US98/27496 



o 

in 



u 

o 
a 
c 



to 

u 



o 
o 

► 

I 

o 
a. 



in: 
o: 

in* 



cm: 
ro: 

5; 
o 



in: 
ro: 

<ri: 
in: 



8i 

to: 

5; 
o 

K) 

NO; 



a: 



K 
C 

c 



CO 

> 

o 

0. 
* 

£ 
e 

8 

u 



ov 

: cm: 
i • 

: 8: 



= 18 

: cm 
: ro 

5 
o 

3 



w: 

co: 

Si 



\2 E 



: w: 

j n: 



X: 
o: 



L 
« 

E 
o 

x; 

Hi 



tt: 
< 



: on 

• CM 

; i 
: o 



i 



' on- 

: cm: 

: cm. 



IK 
;» 

o 
o 

ro 
m> 



: m 



: ro: 
; cm: 



s 

1 



u 
a! 



O v 

« X 

«» _ *~ 

E * 2 

a» * s 3 

z a u u 

<2<3 s 



o 



u 
c 



111 5 
|0 O u3 iZ 



0\ 



•J* 

fo: 



<• 
a : 

x: 

o: 



% 

I- 
0) 



O 

-J' 

foT 
• < 



£ 

N> 
00 

on 
M 

P 



1 

o: 
ll: 

<: 
u: 
u.: 
o: 

X; 
<: 
tt : 

x: 
2 
X; 



:cm: 



?! 

I 



ro 

- co 
: on 
• w 

id> 

: cm 
: r- 

ro 

cm 



i 

I 

Q> 
N) 
4 



: cm: 



: ro 

• 00 

: on 

• CM 

: o 



3: 

o: 



<: 

u: 



K 



ro 

: cm 



Si 

o: 



<: 

u: 
a.: 
o: 

X; 
<: 
cq: 



(5 



: ro 

• 00 

: <a 

! 

: w 

: CM 



H 
CO 



a 

if 

o 

► 

c 



> 00> 

: o%: 



: in: 



- oo* 
: on: 



OL 



; < 



co: 
on 
»: 

H* 



a 



: co: 

• ON* 



• CM 



1 "O 

: < 



: oo : 

. ON* 



to; 
H- 



■ o 



WO 99/33016 



PCT/US98/27496 



11111 

la 



x 

i 

0) 

o 



q 



in 
w 
ov 
a, in 
o; * 



8 

lb IN 

o; in 



1 



o- o 
w: cn 

w': b 
oo; in 



s< :ro 



: o 
• in 

: ro 
o; — 



©• ID* 



m 

T- 

d 



in 



c.K 

ft 1 

o 



WO 99/33016 PCT/US98/27496 




WO 99/33016 



3fr/t>r 



PCIYUS98/27496 




WO 99/33016 



PCT/US98/27496 



FIG. 145 



FIG. 145 A 


FIG. 145 B 


FIG. 145 C 


FIG. 145 D 



WO 99/33016 PCT/US98/27496 



MVS date! Mega PO ICust Name/PO 


*— Terrn-BTO 


! Item Sold Description / Mfr 


10/2/97 ! 




[UNION BANK OF CALIFORNIA 


jVECTRA VL5 DT 5/166 MMX 1 6MB 1 


M97-25641 


!NoP 


16310009524 


iNIOi 


[HPPC'S ~ 


1/8/97 I 




j ORACLE 




iTRNSCVR MICRO MOD 10B5 


M97-24289 


INoP 


1230419 


|N45 j 


jDIGI } 


oo/oo/oo ! 




i 




lAPEX 4.6GB PCI INT 5.25HH SCSI2 < 


M96-21656 


iNoP 


i 


j | 


IPINNACLE MICRO j 


00/00/00 I 


1 SOMDR 4.6GB OPTL MED REWRITABLE 


M96-21656 


|NoP 


j j iPiNNACLE " ] 


1 /8/97 1 


Goldman^ Sachs 




}PC-TRAC PS/2 TRACKBALL 


M97-24287 


INoP 


S0108C820 


]N3oT 


IMICROSPEED INC. "] 


00/00/00 i 


[RECORDABLE BLANK CD 650MB 4X 1 


M96-22125 


INoP 


I | {SONY CORPORATION OF AMERicA "I 


1 /8/97 I 


PACIFIC BELL BAY UNIT 


LASERJET TONER 4 4M 4PLUS 4M P 


M97-24288 


|NoP 


AJ0EN95 


Nio ! 


[HP PRINTERS ] 


1 /8/97 1 


ORACLE 




18-PORT 10BT ETHHUB 


M97-24289 


iNoP 


230419 


IN45 1 


iDIGI ] 


00/00/00! 


1CD0-74S2 RECORD ABLE 1 0-PK SILK 


M96-22758 


INoP 


1 j ISONY MEDIA ] 


oo/oo/oo! 


^ jLS- 1 20 DRIVE 3.5HH 1 20MB READ/ 


M96-22875 


iNoP 


i j jCOMPAQ COMPUTER CORPORATION] 


00/00/00 I ! 


{LASERJET SSI 5SIMX TONER CARTR 


M96-23636 


INoP | 




i ! 


(HP PRINTERS ] 


oo/oo/oo! 








IDLT COMPACT APE IIIXT 30GB 7PK 


M96-23639 


E>P ] 






lADIC | 


00/00/00 I 


i 

J 






IEZ135 135MB CARTRIDGE SNGL PK 


M96-23704 


jNoP ! 




I i 


[SYQUEST ] 


4 IjJ 



FIG. 145 A 



WO 99/33016 



PCT/US98/27496 



g= Items Sold: 13138 of 131 



Qty i Sprice 


height /ETA! Scost / Pcost 


Vendor /Conf • 


M2500 24XCD VFV V 1 




1^229.00 


Merisel 


*"'*T' t 




1 .227.00 


6123589 


i 

■ . *•*».».»»..*...*.„„.. 




44.28 


Merisel 


M : 




44.00 


05517214 


1.5MB 17MS V/SCSI 1 ! 




1 ,434.07 


TECHDATA 


H 1 




1 .370.00 


8791827 


I i 




162.05 


Merisel 

05582632 


12 I 




138.00 


i 




66.14 


MicroD 


b t 




66.14 


50-81179 


jPK 74 MINUTES 




6.76 


MicroD 


!20 | 




5.85 




LUS YIELD-6800 PAG ! 




89.00 


Merisel 


|2 | 




89.00 


05517214 


J ' r- 

i 




204.12 jMerisel 






199.001 05517214 


SCREEN COMPATIBLE I 




59.36 jTECHDATA 


, r f _ 




59.50! 5591827 


WRITE ABLE TO 1 .44MB I 




194.87 iMicroD 


li [ 




193.(M>j 8400326 


IDGE [ 




157.21 jTECHDATA 


h 1 ! 




157.001 5591827 






295.54 jTECHDATA 






295.001 7384066 


HARD DISK CART FOR i 




19.00 jTECHDATA 


ho [ 




17.30! 5591827 



FIG. 145 B 



PCT/US98/27496 



\ Mfr / Vendor(PN) 


Lories e /Leost 


Rebate 


ID4594B*ABA 




Test 


=27609 






;M!L4340M 




Test 


162704 




IAPEX4.6GBPCI 




lest 


=630172 






I0MDR 4.6 GB 




Test 


179769 




[PD^SO 




ies\ 


1256226 






[CD0-74A 




Test m . 


|314732 ' 




1?22?8A 




Test j 


140901 






[MIL4710H 




Test 


|02223 






|CWr74SZ 




Test 


1603339 




ll?sp6 1-001 i 


Test | 


1437119 | 




fe??09A i 


1*5! | 

r 

! 


1546065 ! j 


139-1050-11 i 


Test j 


1048466 j 


1 

i 



SLQ?2?.3/*fl^5 } {Test 



1789369 



FIG. 145 C 



WO 99/3301 6 PCT/US98/27496 



mm 



Special Pcomments 






j>>Cy^R?tTy 


! 


} 






i 


jETA^S^ 




? 1 _ 






































U M tH MH « H ... H M. HMHHM .,„ H . 

t 




jnjt 





FIG. 145 D 



WO 99/33016 PCTAJS98/27496 



FIG. 146 



FIG. 146 A 



FIG. 146 B 



FIG. 146 C 



WO 99/33016 PCT/US98/27496 







MVS date! Mega PO jCust Name/PO 


* — Term-BTO litem sold Description / 1" 


10/2/97 ! 


INop""" 


! 


UNION BANK OF CALIFORNIA 


jVECTRA VL5 DT 5/1 66 MMX 1 


M97-25641 


16310009524 


|N10 | 


jHP PC'S ! 


1 /8/97 \ 




■ORACLE 




iTRNSCVR MICRO MOD 10B5 


M97-24289 


|NoP 


1230419 


|N45 i 


Eioi ! 


00/00/00 ! 




j 






{APEX 4.6GB PCI INT 5.25HH SI 


M96-21656 


|NoP 


! 
! 




i : 
j t 


jpiNNACLE MICRO ] 


00/00/00 1 




I 






10MDR 4.6GB OPTL MED REWRT 


M96-21656 


iNoP 


i 




1 i 


IpInnacle 1 


1 Z8/97 i 




IGoldman . Sachs 




iPC-TRAC PS/2 TRACKBALL 


M97-24287 


iNoP 




S0108C820 


IN30 


iMicROSPEED INC. 1 


99.t99J.99L„ 
M96-22i25" 


Inop"*" 






I i 
1 J 


jRECORDABLEB 

Isony cor For atIon of amer! 


1 /8/97_ | 
M97-T4288" 


INoP 




PA?)ncMLLMLy.NJI 

AJ0BN95 [MoT"" 


1l aser jet toner 4 4m 4plus 

]hp^"r^ters ! 


1 Z8/97 ! 


ORACLE 




I8-P0RT 10BT ETH HUB 


M97-24289 


INoP 




230419 


jN45j 


Idigi j 


00/00/00! 


ICD0-74SZ RECORD ABLE 1 0-PK 


M96-22758 


INoP 






! ! 


jSONY MEDIA 1 


00/00/00 1 










lLS-1 20 DRIVE 3.5HH 1 20MB R 


M96-22875 


jNoP 






i \ 


iCOMP AO COMPUTER CORPOR | 


00/00/00 i 






• 




[LASERJET 5SI 5SIMX TONER C 


M96-23636 


iNoP 




i 


j \ 


|HP PRINTERS I 


oo/oo/oo ! 










iDLT COMPACT APE IIIXT 30GB 


M96-23639 


iNoP 




| 


\ \ 


|adic ! 


00/00/00! 






: 

i 




1EZ135 135MB CARTRIDGE SNC 


M96-23704 


jNoP 




t 
i 


\ \ 


fsYOUEST I 


<|iw| 





FIG. 146 A 



WO 99/33016 PCT/US98/27496 

to/or 





Ifr Qty 


Order /ETA tpd ETA /Status! Epd Condition 


6MB M2500 24XCD VFV 


10/2/97 16/17/98 


M 


(Back order 




J /8/97 1 i 


h 


1 


:SI2 4,5MB 17MS V/SCS 


1/21/97 1 


jl 


1 


FABLE 


2/3/97 1 


12 


1 




1 /9 /97 1 ! 


12 




3 4X 1PK 74 MINUTES 


2/10/97 1 j 


120 




4M PLUS YIELD-6800P 


( 1/8/97 _ 1 j 


12 






1 /8/97 1 { 


h 




SILK SCREEN COMPATIBL 


8/15/96 1 ] 


ii 




E AD /WRITE ABLE TO 1.44 


1/8/97 1 j 






ARTRIDGE 


1/21/97 1 | 


h 




7PK 


10/8/96 1 ] 


jli (Open source complete 


iL PK HARD DISK CART F0|1 /21 /97 1 ] 


Ti 6 T i 


FIG. 146 B 



WO 99/33016 



PCT/US98/27496 



Mfr /Vendor PHI Vendor /Conf • j Ecomments 



D4594B«ABA 


I Merisel ! 


27809 


|6123589 j j 


MIL4340M 


1 Merisel j 


62704 


] 055 1721 4 j j 


APEX4.6GBPCI 


jTECHD AT A | 


630172 


J8791827 j ! 


OMDR 4.6 GB 


! Merisel I 


79769 


105582632 j j 


PD-250 


iMicroD j 


256226 


150-81179 i I 


CDQ-74A 


iMicroD 1 


314732 | i j 


92298A 


j Merisel I 


40901 


105517214 j f 


MIL4710H 


1 Merisel i 


02223 


]05517214 1 | 


CDQ-74SZ 


jTECHD AT A \ 


803339 


15591827 j f 


185061-001 


iMicroD I 


437119 


18400326 I T 


C3909A 


Itechdata i 


546065 


15591827 j f 


39-1050-11 


iTECHDATA ! 


048400 


|7384066 I ] 


JS1 07793/SQ1 35 jTECHD AT A I 


789369 


15591827 j | 



FIG. 146 C 



WO 99/33016 PCT/US98/27496 



FIG. 147 



FIG. 147 A 



FIG. 147 B 



FIG. 147 C 



WO 99/3301 6 PCT/US98/27496 



MVS date! Mega PO 


Oust Name/PO *— Term-BTO 


10/2/97 ! 


UNION BANK OF CALIFORNIA 


M97-25641 |NoP 


631^9524 |N10| 


1 /8/97 1 


ORACLE 


M97-24289 ]NoP 


230419 |N45| 


op/oo/ooj 




M96-21656 InoP 


i i ; 

i t : 


00/00/00 1 




M96-21656 jNoP 


7 _ T _ , 


1/8/97. Ji 


Goldman j Sachs 


M97-24287 ]noP ' 


S0108C820 1N30 


pp/pq/oo! 




M96-22125 |NoP 


I ! " ] 


1/8/97 | 


PACIFIC BELL BAY UNIT 


M97-24288 TnoP ' 


AJ0EN95 InTo I 


1 /8/97 I 


ORACLE 


M97-24289 |NoP 


230419 FN45| 


00/00/00 1 




M96-22758 |NoP 


T ~7 


oo/oo/ooi i 


M96-22875 |NoP j j j 


oo/oo/oo| ] | 


M96-23636 [NoP | T [ j 


oo/oo/ooj I \ 


M96-23639 iNoP j IT"! 


00/00 /00| ! | 


M96-23704 INoP | I [ | 


4 



FIG. 147 A 



1 



WO 99/33016 



PCT/US98/27496 



litems Sold: 13138 of 1311 



Item sold Description / Mfr — PS Hum Qty 


Order /ETA I 


VECTR A VL5 DT 5/1 66 MMX 1 6MB M2500 24XCD VFV W 


10/2/97 1 


HP PC'S i 


h 


: 
: 
1 


TRNSCVR MICRO MOD 10B5 


1/8/97 ! 


dJgi 1 ~ fi 


»•••«—•—*••« « «< 


;APEX 4.6GB PCI INT 5.25HH SCSI2 4.5MB 17MS W/SCSI 1 


1/21/97 


IP INN ACLE MICRO 


h 


! 


;OMDR 4.6GB OPTL MED REWRITABLE 


2/3/97 ] 


FiNNACLE | \i 


i 


PC-TRAC PS/2 TRACKBALL 


1/9/97 ! 


MICROSPEED INC. j 


12 


I 
t 
t 


Bi?9 R P ABLE BLAN K CD 650MB 4X 1PK 74 MINUTES 


[2/10/97 I 


iSONY CORPORATION OF AMERj 


20 


i 
i 


LASERJET TONER 4 4M 4PLUS 4M PLUS YIELD-6800 PAG it /8/97 j 


HP PRINTERS j 


2 


i 


8-PORT 10BT ETH HUB 


1/8/97 


DIGI | 


1 




9J>9.l7A sz RECORD ABLE10-PK SILK SCREEN COMPATIBLE 


8/15/96 


SONY MEDIA j 


1 




LS-120 DRIVE 3.5HH 120MB RE AD /WRITE ABLE TO 1 .44M 


1/8/97 ! 


COMPAQ COMPUTER CORPOR | 


1 


"\ 
J 


LASERJET SSI 5SIMX TONER CARTRIDGE 


1/21/97 1 


HP PRINTERS j 


1 


| 


DLT COMPACT APE IIIXT 30GB 7PK 


10/8/96 j 


ADIC 


1 


i 


E2135 135MB CARTRIDGE SNGL PK HARD DISK CART FOR 


1/21/97 1 


SYQUEST | 1 


10 


I 



FIG. 147 B 



WO 99/3301 6 PCT/US98/27496 



Mfr/Vendor PW j Vendor /Conf •Receive Condition / Rcomments _^ 

MS^B^ABA iMerisel I = 

27809 "" 1*S1 23589 j ' " 



MIL4340M iMerweJ 

62704" 1055^7214 



,APEX4.6GBPC! M 


JTECHDATA _ j 


630172 


18791827 i 


0MDR 4.6 GB 


jMerisel j 


79769 


105582632 | 


PD-250 


iMicroD m i 


256226 


150-81179 | 


CD0:74A 


[MicroD i 


314732 1 j 


J92298A 


iMerisel i 


40901 


105517214 f 


MIL4710H 


IMerisel ! 


02223 


1*05517214 ] 


CDQ-74SZ 


ITECHDATA j 


803339 


|5591827 j 


185061-001 


JMicroD ! 


1437119 


1*8400326 ] 


C3909A 


jTECHDATA 1 


;546065 


15591827 j 


39-1050-11 


iTECHDATA ! 


1 048400 


173840(56 | 


IS107793/SQ135 ITECHDATA | 


1789369 


15591827 j 



FIG. 147 C 



WO 99/33016 PCT/US98/27496 



FIG. 148 



FIG. 148 A 



FIG. 148 B 



FIG. 148 C 



WO 99/33016 PCT/US98/27496 





MVS datej Mega PO 


jCust Name/PO *~Term-BTO | 


10/2/97 ! 




jUNION BANK OF CALIFORNIA 


M97-25641 


;NoP 


16310009524 W6\ | 


1/8/97 I 




! ORACLE j 


M97-24289 


INoP 


1230419 lN45l 


00/00/00 i I 


M96-21656 


INoP ! | 1 | 


00/00/00 i 


M96-21656 


INoP 


\ j j ; 


1/8/97 i 


Goldman, Sachs 


M97-24287 


: NoP 


S0108C820 |N30 j 


99/99/9.91 








No? 


, ^ — 


1/8/97 | 


JPACIFICBELL BAY UNIT 


M97-24288 


NoP 


AJ0EN95 jN*l6 j 


1/8/97 1 


ORACLE 


M97-24289 IfioP 


230419 |N45| 


00/00/00 1 




M96-22758 


NoP 


| ! 


00/00/00! I 


M96-22875 JNoP 


n i 


00/00/00! | 


M96-23636 |NoP 


~ **t r — "i 

: t : 

i i ; 


op/oo/ooi j | 


M96-23639 INoP 


i 1 ! 


op/oo/ooi | | 


M96-23704 INoP | f I ™'l 


4\m 



FIG. 148 A 



WO 99/33016 

*'//<)/ 



Iteims Sold: 13138 of 131====^^^^^ 



Item sold Description / Mfr Qty Hfr /Vendor PH j Vendor /Conf • 

1 VECTRA^ y*ris*} 

yppC-sT [ jl" j27809 lis 123589 



TRNSCVR MICRO MOD 10B5 


IMIL4340M 1 Merisel 


DIG) \ jl 


|62704 105517214 


APEX 4.6GB PCI INT 5.25HH SCSI2 4.5MB 1 7MS V/SCSI 1 ;APEX4.6GBPCI iTECHDATA 


PINNACLE MICRO f 11 


1630172 18791827 


iOMDR 4.6GB OPTL MED REWRITABLE 


IOMDR 4.6 GB 


Merisel 


IpiNNACLE I 12 


I79769 


05582632 


1?£*I?A?.P.§/J?J.BAC v 

HicROSPEEDTNC. | ~']2 


.jPD^SO 

1256226 


MicroD 

50-81179 


RECORDABLE BLANK CD 650MB 4X 1 PK 74 MINUTES 


1CDQ-74A 


MicroD 


SONY CORPORATION OF AMERICA ! i20 


[314732 




k6.?£!^ 

HP PRINTERS |2 ""'[40901 


Merisel _ 

05517214 


8-PORT 10BT ETH HUB 

DIGI j jl 


JMJL4710H 

]02223 


Merisel 

05517214 


CDQ-74SZ RECORDABLE 1 0-PK SILK SCREEN COMPATIBLE ICDQ-74SZ 


TECHDATA 


SONY MEDIA I h 


1803339 


5591827 


iS-120 DRIVE 3.5HH 120MB RE AD /WRITE ABLE TO 1 .44M 1185061-001 


MicroD 


jCOMP AO COMPUTER CORPORATION j 11 


[437119 


18400326 


LASERJET SSI 5SIMX TONER CARTRIDGE 


1C3909A 


ITECHDATA 


!HP PRINTERS i ll 


1546065 


15591827 


DLT COMPACT APE IIIXT 30GB 7PK 


139-1050-11 


TECHDATA 


ADIC j jl 


I048400 


17384066 


EZ135 135MB CARTRIDGE SNGL PK HARD DISK CART FOR 
SYQUEST j jlO 


}S107793/Sqi35 iTECHDATA 
1789369 15591827 



I 



PCT/US98/27496 



FIG. 148 B 



WO 99/33016 



PCT/US98/27496 



to/** 



Install /Date jlnstall Groupjicomtnents / ETA 



Test 



Test 



Test 



Test 



Test 



Test 



Test 



Test 



Test 



Test 



Test 



Test 



Test 



31 



FIG. 148 C 



WO 99/33016 PCT/US98/27496 



FIG. 149 



FIG. 149 A 



FIG. 149 B 



FIG. 149 C 



WO 99/33016 PCT/US98/27496 





MVS date. Mega PO jdist Name/PO 


* — Term-BTO litem sold Description / Mfr 


10/2/97 ! 




1UNI0N BANK OF CALIFORNIA 


{VECTR A VL5 DT 5/1 66 MMX 1 6MB I 


M97-25641 


iNoP 


16310009524 


jNIOi 


[HP PC'S I 


1 /8/97 I 


\ ORACLE 




1TRNSCVR MICRO MOD 10B5 


M97-24289 


!NoP 


230419 


;N45 i 


IdIGI ! 


00/00/00! 


! APEX 4 .6GB PCI INT 5 .25HH SCS 12 < 


M96-21656 


INoP 


! ! Ipinnacle MICRO ] 


00/00/00 \ 


jOMDR 4.6GB OPTL MED REWRITABLE 


M96-21656 


|NoP 


1 ! |p!nnacle " " j 


!./ 8/97 1 


Goldman, Sachs 




IPC-TRAC PS/2 TRACKBALL 


M97-24287 


INoP 


S0108C820 


;N30 I 


jMicROSPEED INC. j 


00/00/00 i 


_ IRECORDABLE BLANK CD 650MB 4X ' 


M96-22125 


INoP 


j j jSONY CORPORATION OF AMERicA ! 


!/? /97 i 


PACIFIC BELL BAY UNIT 


jLASERJET TONER 4 4M 4PLUS 4M P 


M97-24288 


jNoP 


AJ0EN95 


|N10 1 


Ihp printers j 


1 /8/97 ! 


ORACLE 




18-PORT 10BT ETH HUB 


M97-24289 


INoP 


230419 


|N45j 


Idigi ™"j 


00^/00! 








ICDQ-74SZ RECORD ABLE10-PK SILK 


M96-22758 


ISop 




: i 
: i 


[SONY MEDIA ] 


00/00/00 I 


i 






IS- 1 20 DR I VE 3 ,5HH 1 20MB RE AD / 


M96-22875 


jNoP 1 




Y ? 

! i 


jCOMPAO COMPUTER CORPORATION! 


00/00/00! 


! 






}L ASERJET 5S 1 5S IMX TONER C ARTR 


M96-23636 


|NoP "j 






!HP PRINTERS j 


00/00/00! 


I 






_ m !DLT COMPACT APE ItIXT 30GB 7PK 


M96-23639 


|NoP 




: T 
: i 


Iadic j 


00/00/00! 


"*T j 






IEZ135 135MB CARTRIDGE SNGL PK 1 












iovm ircT 




mil 



FIG. 149 A 



WO 99/33016 PCT/US98/27496 



ms Sold: 13138 of 131 



Qty Hfr /Vendor PNjVendor/Conf •jOrder/Recd 



M2500 24XCI> VFV W 


jM^B^A 
I27B09 


jMgrjsel 

'H6T235B9 


1.10/2./97 

i 




1MIL4340M 


1 Merisel 


1 1/8/97 


i ii 


162704 


105517214 


! 


4.5MB 17MS V/SCSI 1 


IAPEX4.6GBPCI 


iTECHDATA 


h/21/97 


1 h 


1630172 


18791827 


1 




I0MDR 4.6 GB 


1 Merisel 


12/3/97 


1 12 


179769 


105582632 


i 




IPD-250 


— 1 

IMicroD 


1 1/9/97 


1 12 


1256226 


150-81179 


; 


1PK 74 MINUTES 

1 120 


]CDp-74A 
1314732 


IMicroD 


12/10/97 
............ 

{ 


'LUS YIELD-6800PAG;92298A 
\2 140901 


^ j Merisel 

^'{05517214 


11/8/97 

j 




{MJL47J0H 


i Merisel 


1 1/8/97 




|02223 


{05517214 


1 
t 


SCREEN COMPATIBLE 


ICDQ-74SZ 


_iTECHDATA im 


18/15/96 


! h 


1803339 


"15591827 


| 


[ jl 


1185061-001 
1437119 


[MicroD 

18400326 


11/8/97 

1 


tIDGE 


1C3909A 


iTECHDATA 


1 1/21/97 


i h 


1546065 


15591827 


I 






139-1050-11 


iTECHDATA 


MO/8/96 


i h 


1048400 


17384066 




HARD DISK CART FOR 


IS 1 07793 /SQ 135 iTECHDATA 


!l/21/97 


i ^ 


±ulwls 







I 



FIG. 149 B 



WO 99/33016 PCT/US98/27496 



Ship Group 


Scomments 



































































































FIG. 149 C 



WO 99/33016 



PCT/US98/27496 



Quote 



corrective 
measure/ 
user action 



NO 



Percolation/Verification 
sales order/item sold 



sales 
order 



1 .items with higher Scost 
than Sprice 

2.items with higher Pcost 
than Scost 

3.items on back order with 
groups 

4.item on rush orders 
S.items with back order 
received in no partial sales 
order 

6.items with promotions cash 
7.items w/ rebate to customer 
from mfg ./vendor cash 
8.items w/ rebateto customer 
from mfg ./vendor non-cash 
9.items w/promotions non 
cash to us 

lO.items w/ mfg. rebate(toss) 
other items 




Level 1 Sales order 
Verification/Percolation 



1. sales order on credit on hold 

2. sales order exceeding credit 
limits 

3. sales order with cust invoice 
past due 60 days 

4.. sales order w mismatch FOB 
term, origin w/ no fright charge or 
destination w/ freight charge 
5. sales order w/ installation qty 
of parts in compatible, not equal 
to qty of primary system 
6..sales order wi install charge 
not equal to install qty x unit 
installation charge 

7. sales order wi installation 

8. sales order with restricted ship 
group mismatch against installa- 
tion group 

9. sales order with ship group 

10. sales order w/ partial ahip. 
11. other sales order 



Level 2 Item sold 
Verification/Percolation 



Prepare purchase order 

request. 
Use default vendor or re- 
select vendor 



posting order 
via web/email file transmit 
to selected vendors 



posting bid 
via web/email file transmit 
to selected vendors 



i 



ship to us 
or drop 
ship to 

customer 



Bid response via web 



FIG. 150 



WO 99/33016 . PCT/US98/27496 

Vf/<3r 



Percolation/Verification 
Receiving 



Sales order need 
to be received 



Items to be 
received 



correc- 
tive 
mea- 
sure/ 
user 
action 



NO 



1 .Items cancelled 
2.ltems to be refused 
3.ltems with COD 
4.ltems with express delivery 
S.ltems for replacement orders 
6.ltems marked back order 
7.ltems in a auto-tracked sales 
order 

8. Simple items holding up 
installation 

9. Simple items holding up ship 
group 

lO.General items 

RMA item need de-install 



Level 1 verification/Percolation 
sales order to be received 
already processed by purchasing 



Receiving sales order 

Sales order to be refused /cancelled 

Sales order with COD item 

Sales order with express delivery 

Sales order marked for special tracking 

Replacement sales order 

No partial sales with one item left(mws 

must have more than one item , if one 

item do not show) 

Restricted partial with one item left 

(same as above) 

Sales order expecting back order items 
Sales order with installation 
Sales order without installation 
Inventory sales order 
Supply sales order 

RMA returns expected from customer 
RMA returns expected from vendor 
RMA requiring install / de-install 




Level 2 Item sold 
Verification/Percolation 



S YES 


Start receiving process 





posting receiving status 
via web/email file transmit 
to selected vendors 


Optional »» 





FIG. 151 



WO 99/33016 / /v PCT/US98/27496 



PercolationA/erification 
Shipping 



Sales order need 
to be shipped 



Items to be 
shipped 



correc- 
tive 
mea- 
sure/ 
user 
action 



NO 



Litems cancelled 

2. Items with COD 

3. Items for will call 

4.ltems with express delivery 

5. Items with auto tracking 

6.ltems in completed installation 

RMA item need re-install 



<Tteady td>^«- 



Level 1 Verification/Percolation 
sales order to be received 



Shipping sales order 

Sales order to be cancelled /do not 
ship 

Sales order with COD item 
Sales order with will call 
Sales order need express delivery 
Sales order marked for special track- 
ing 

Sales with completed installation 
Sales order with over 100 items 
Sales order with ship groups but no 
installation required 

RMA return to Customer 

RMA return to Vendor 

RMA requiring install/de-install 



Level 2 Item sold 
Verification/Percolation 



{ YES 


Start shipping process 


— ». 

Optional ^ 


posting shipping status 
via web/email file transmit 
to selected vendors 





FIG. 152 



1 



WO 99/33016 PCT/US98/27496 



Percolation/Verification 
Installation/Assemble 



Sales order with 
installation/assemble 
requirement 



corrective 
measure/ 
user action 



NO 




1 . Sales order with large qty of installa- 
tion 

2.Sales order ready for software net- 
work integration 

3.sales order ready for assembling 
sales order ready for installation 
4.Sales order missing one last item 
S.Sales order with defective compo- 
nent for RMA process 
6.Sales order with defective compo- 
nent 

complete with RMA waiting for vendor 
shipment. 



RMA need de-install 

RMA need re-install 

RMA for warranty repair off-site,on-site 

RMA for out of warranty repair off-site, 

on-site. 



YES 


Start installation process 


► 








posting installation 
via web/email file transmit 
to selected vendors 


I Optional ► 





FIG. 153 



WO 99/33016 



PCT/US98/27496 



Sell/Demand Chain 



Supply/Assembly Chain 



URL link from 
customer web 
site 




Product file 






i 




User demand 

r 


Quote 




PID 
PPL 
Product 











Update & 
maintain file of 
components 



Total 
component 
requirement 
for assemble 
product 



Qty 



Unique set of 
components for 
specific SKUs 



Display 



SKU& 
qty 



Item sold with 
assemble 
requirement 



Item sold 

Complete no 
assemble compo- 
nents required 



purchasable 
items or 
assembled items 



Assemb 



ed Items 



Component PSRI with 
bill of material 



Different vendor web site 
Vendor assembly program 
or vendor supplying 
components 



Different mfr. web site 
Vendor assembly program 
or vendor supplying 
components 



PSRI 

(Purchase/Ship/Receive/ 
Install) 

Virtual inventory and no B/O 
reduces DOA (single han- 
dling) compress order cycle 
time reduces to single order 
cycle allow components sub- 
stitutes. 



FIG. 154 



WO 99/33016 



PCT/US98/27496 



Cust. 
Business 
Activities 


Busiest 
Period 
Week 
Month 


Slowest 
Period 
Week 
Month 


















Digital 
file 


Activate 


Cust. 
Access 
group 


Supervisor 
Access 
List name 

1. 


C\i 


CO 


Universal 
Access 


Individual 
Access 


















Digital 
file 


Activate 


Cust 
Security 


2= 

CD 
CO 


Vendor 


Encryption 


ts 

CO 


Security 
Certificate 


VPN 

i 


Inside 
Firewall 

i 












Digital 
file 


Activate 


Cust. 
Payment 


Retrieve 


Credit 
card 

Cr. card 

from lofifw 

limit 

Cr. card 
$ limit 


Check 


EFT 

$ limit 

Daily 
Monthly 








Digital 
file 


Activate 


Cust. 
Cr. 
memo 


%8 E 
























Digital 
file 


Activate 


Cust. 
Invoice 


Retrieve 
Fax 


Mail 

Web 
download 


Cr. apply 
to inv. 


Replace 
invoice 


Frequency 
Weekly 
Daily 












Digital 
file 


Activate 


Cust. 
Tracking 


Serial # 


$ limit 

Per tracking 


Duration 


Qty limit 

Per tracking 


















Digital 
file 


Activate 


Cust 
Shipping 


Method 
UPS 
FedEx 
AirBorne 
Truck 


Pick up 


Hand 
Carry 


Deliver with- 
in building 


Drop 
Ship 


Destina- 
tion 


Origin 


Loading 
Dock 


Packing 
slip 


Partial 


— — (3 

8 & (S 
i id c 

J Q s 


Digital 
file 


Activate 


Cust 
Service 
& Repair 


On-site 


Off-site 


Labor $ 
on site 


Labor $ 
off site 


Part 
stock 


Part 
charge 


Duration 

2, 4, 8, 24, 
48, 72 hrs 


Service 
contract 

1.2, 3 yr 








Digital 
file 


Activate 


Cust 
RMA 


Create 


Save/ 
retrieve 


Modify 


Submit 


$ limit 

Per RMA 


Qty limit 

Per day 


Frequency 

limit 
RMA/day 


Standard 
guide 

Auto 
approved 


Packing 
slip 






Digital 
file 


Activate 


Cust. 
Report 


RMA 

customer 
not shipped 


RMA 

custnot 
received 


RMA 
summary 


PO 

summary 


B/O 
summary 


Tracking 
report 


Period 
limit 


Qty 
report 


Ship 
report 


Rec'd 
report 


Acct. 
invoice 


Payment 


Digital 
file 


Activate 


Cust. 
Order 


Place 

1. 


CM 


co 


Adden- 
dum 

1. 


CM 


CO 


Retrieve 

1. 


CM 


CO 


Cancel 


$ limit 

Per order 


Qty limit 
Per day 


Frequency 

timit 
Order/day 


Tracking 

order 
Per month 


CO 


Digital 
file 


Activate 


Cust. 
Quote 


a> 
cS 
£ 

a 


CM 


CO 


Save/ 
retrieve 
1. 


C\ 


CO 


Modify 

1. 


CM 


CO 


Submit 


$ limit 
per quote 


Qty limit 
Per day 


Frequency 

limit 
Quote/day 


Archive 

limit 
Per month 


75 
> 

UJ 


Digital 
file 


Activate 


Cust 
Price 
update 


Frequency 

Daily 
Weekly 

Monthly 


Minimum 
$ update 


Show new 
product 


Show 
discount 
product 


Pricing 
update 

Cost plus 
Fixed price 


mfr. 
specific 


Show all 
product 


_J 
Q_ 
Q_ 


o 


Digital 
file 


Activate 


Task 


uoijoaies n/A eiejodjOQ 



FIG. 155 



WO 99/33016 / PCT/US98/27496 



Vendor 
Business 
Activities 


Busiest 
Period 
Week 
Month 


Slowest 
Period 
Week 
Month 


















Digital 
file 


Activate 


Vendor 
Access 
group 


m 

CO -> 




CO 


Universal 
Access 


Individual 
Access 


















Digital 
file 


Activate 


Vendor 
Security 


CD 
CO 


Vendor 


Encryption 


H 
LU 
CO 


Security 
Certificate 


VPN 


Inside 
Firewall 












Digital 
file 


Activate 


Vendor 
Payment 


Retrieve 


Credit 
card 

Cr. card 
frequency 
limit 

Cr. card 
$ limit 


Check 


EFT 

$ limit 

Weekly 

Daily 
Monthly 

i 








Digital 
file 


Activate 


Vendor 

Cr. 
memo 


Internal 
External 
























Digital 
file 


Activate 


Vendor 
Invoice 


Retrieve 

Fax 

Mail 

Web 
download 


Cr. apply 
to inv. 


Replace 
invoice 


Frequency 
Weekly 
Daily 












Digital 
file 


Activate 


Vendor 
Tracking 


Serial # 


$ limit 

Per tracking 


Duration 


Qty limit 
Per tracking 


















Digital 
file 


Activate 


Vendor 
Shipping 


Method 
UPS 
FedEx 
AirBorne 
Truck 


Pick up 


Hand 
Carry 


Deliver with- 
in building 


Drop 
Ship 


Destina- 
tion 


Origin 


Loading 
Dock 


Packing 
slip 


Partial 


E 2 © 

m CD C 

3 Q 3 


Digital 
file 


Activate 


Vendor 
Service 
& Repair 


On-site 


Off-site 


Labor$ 
on site 


LaborS 
off site 


Part 
stock 


Part 
charge 


Duration 

2, 4, 8, 24, 
48, 72 hrs 


Service 
contract 

1.2, 3yr 








Digital 
file 


Activate 


Vendor 
RMA 


Create 


Save/ 
retrieve 


Modify 


Submit 


$ limit 
Per RMA 


Qty limit 
Per day 


Frequency 

limit 
RMA/day 


Standard 
guide 

Auto 
approved 


Packing 
slip 






Digital 
file 


Activate 


Vendor 
Report j 


RMA 

customer 
not shipped 


RMA 

custnot 
received 


RMA 
summary 


PO 
summary 


B/O 
summary 


Tracking 
report 


Period 
limit 


Qty 
report 


Ship 
report 


Rec'd 
report 


Acct. 
invoice 


Payment 


Digital 
file 


Activate 


Vendor 
Order 


Place 

1. 




cd 


Adden- 
dum 

1. 


cvi 


CO 


Retrieve 

1. 


CM 


CO 


Cancel 


$ limit 
Per order 


Qty limit 

Per day 


Frequency 

limit 
Order/day 


Tracking 

order 
Per month 


CO 

> 

LU 


Digital 
file 


Activate 


Vednor 
Quote 


Create 




CO 


Save/ 
retrieve 
1. 




CO 


Modify 

1. 


cvi 


CO 


Submit 


$ limit 
per quote 


Qty limit 
Per day 


Frequency 

limit 
Quote/day 


Archive 
limit 
Per month 


75 

iS 


Digital 
file 


Activate 


Vendor 
Price 
update 


Frequency 

Daily 
Weekly 

Monthly 


Minimum 
$ update 


Show new 
product 


Show 
discount 
product 


Pricing 
update 

Cost plus 
Fixed price 


mfr. 
specific 


Show all 
product 


_i 
Q. 
Q_ 


G 

CL 


Digital 
file 


Activate 


Task 


uotpeias n/a Q^JOdJOQ 



FIG. 156 



1 



WO 99/33016 



PCT/US98/27496 



DATABASE APPLICATION CLIENT 



SALES 
FORCE 
AUTOMATION 



END-TO-END 
BUSINESS 
PROCESS 



DATA BASE 
APPLICATION 
SERVER 



WEB-ENABLED 
DBMS 

DATABASE 



FIG. 157 



i 



WO 99/33016 



!rA>r 



PCT/US98/27496 



Sales expense report 
Daily/weekly/monthly 
Destination 

1 . Transportation 
Mileage/$ rental 
Parking fee 

Others - tolls, extra fee 

2. Lodges, rooms, meals, 
phone, others 

3. Entertainment - name, date 
time, company, nature, location 



Reward 
Structure 



Payroll Comparation 



Commission 
Base Salary 

Expense 
Goal Bonus 
Extra commission 



Sales Force Automation 
Activity log - Actual time & date daily activities by 
customer 

Intelligent notes - Sortable & editable 
Trigger - call follow up 

- major opportunities 

1 . Lineage 

2. Dept. classification 

3. Time, date, note, menu 

4. Follow up triggers 

5. Personal info, data 

6. Major opportunity 

7. Virtual secretary 

8. Proposal template 



J 



Sales Forecast 
1 . Historical base 

a. Customer 

b. Period, $, qty 

c. Details 
mfr., platform/type 
Equipments 

d. Bill of materials by 
type of equipments 

e. Return 

f. Internal 

g. Months 
Corresponding 
period 

Representing peri 
od 

. Market projection 
based 

3. Prospecting based 



i 




ii 




WUBER 


y 



Summary Display 
Customer file (working knowledge base) 
Qualitative (Individual File) 



1 . Customer company name 

2. Industry type/size 



Address 
Address 



3. Menu for dept. (user editable) 
"j^ |4. Menu for title 
Purchase 

Finance . Bu V er 5. Name 
Marketing 



7. Assistant 



Buyer 
Manager 
Director 
VP 



Level 1 . 
Level 2 . 
Level 3 . 



8. Back up 




Hobby 
Birthday 
Family 
Education 
Phone 
Fax 



6. Supervisor 



Level 1 . 
Level 2 . 
Level 3 . 



Activity summary display quantitative (result knowledge base) 



$ Sales 



Last 
year 



This 
year 



Last 
month 



Max 
pick 
month 



Mln. 



B/0 



RMA 



Ship to 
date 



Cancel 
orders 



Payment 
history 



Cust. 
inv. 
history 



Ship, 
history 



RMA 
history 



$P0 



Qty 

Durati 
on 



FIG. 158 



WO 99/33016 , PCT/US98/27496 



FIG. 159 



FIG. 159A 



FIG. 159B 



FIG. 159C 



WO 99/33016 



PCT/US98/27496 



01 



CD 
CD 

c 

CO 

o 

X 



o 
Q- 

*s 

c 

H 
o 



c 

CO 

o 

X 



CD 
CO 
£ 

co 
o 

X 



a) 

•CO 

c 

CD 

u 

X 



a> 
co 
c 

CO 

si- 
o 

X 



u 
o 

I— 
CL 

cb 
£ 

CO 

</> 

CO 

c 

<0 
X 



CO 
CO 

c 

CO. 

u 

X 



o 

L- 

a. 

£ 
CO 

CO 

CD 
CO 

c 

CO 

o 

X 







CO 


CD 


> 


> 




a> 


L> 


u 


a> 




u 


£ 






u 


a 


3' 


.3 


•o 


TO 






e 


S 


CL 


a. 


CO 


CO 


c. 


c 




o 


e. 


u 


3= 





CD 
EE 



WO 99/33016 PCT/US98/27496 



"D 




























ire 


'/3> 


CD 




ire 




















3 


S - 




=7) 


3 




















OT 


O 




C 


or 


o 




CD 








CD 






re 


CD 


rtsreqi 


o 


CD 
L_ 


CD 




—J. 


*o 

CD 






-J 


"O 

CD 




U 


/ice 




o 




X 


CO 






X 


(0 






rvi 


CO 


E 


TD 


o 

CD 


^? 
+•* 


"O 

CD 




o 
CO 


! P 

• 


P? 


CD 


■ CO 


c 


CD 


CD 


.CD'. 


o 


o 


CO 


Q) . 


o 


o 


CO 


a. 


CO 


CD 




a. 


CO 


§ 






~n 
_j 


£Z. 




A— 


ID 


CD 


CD 


Q 


CO 


CD 


CD 


CL 


■o 


TD 


*o 


CD 
Q. 




X) 


T3 




•w 






•*-« 






CD 


CD 


CD 


CD 


CD 


CD 


5> 


* Vf 


O 


o 




CO 


Q 


C. 


C 


C 


P 


c 


c 


■.c 


a. 


a. 




CD 


CD 


CD 




CD 


CD 


CD 


c 


= C 


ai 


CD 


c 


c 


o 


CL 


CL 


CL 


O 


CL 


Cl 


CL 


Q 


O 


P 


O 


a 


o 


z 


O 


P 


O 




o 


O 


O 


3> 


3> 




ZD 


ZD 




















Warraif 


C 


•«-». 
























CD 

: L- 
I- 

(0 


Warran 


Warran 


Warran 


Warran 


card 


card 


card 


card 


memo 


memo 


memo 


;merno 


*- 




A_ 




L- 




•*-> 














4-1 


p 


p 


CD 




u. 






















CD 


CD 


CD 


"5 






■5 






TD 






>•-» 


"O 


TJ 


■o 


"O 


CD 


CD 


CD 


CD 


CD 


CD 


CD 


CO 




3 


c 


C 


C 




U 


L. 


L_ 




L..: 


U 


L_ 


1_ 


o 


o 




=) 






O 




U 


u 


L) 




U 


U 






























CD 


d) 




0) 


CO 


CD 


■5 


■o 






"O 




• 5 


■a 


O 


o 


O 


u 


u 


O 


CD 


CD 


e 


£ 


CD, 


£ 


CD 


£ 




CD 


CD 


CD 




CD 


l_ 


L. 






L_. 




L. 












O 


a 


CJ 


O 


V 


U 


O 


U 


O. 
0) 
L. 
\ 


5. 

CD 


CL 




Ct 


a. 


u 


L... 


L_ 


u 


L_ 




C 




Q> 


£ 


CD 


£ 


o 


o 

V- 


O 


o 

w 


O 

w 


o 

V- 


o 


o 


U 


■ 


ti. 


i_ 




U 










E 




c 


E 


*S 












■E 


E. 


E 


E 


E 






<P 


CD. 


5 


5 




3 


3" 


3 


3" 


3 




3 


3 


Q. 


CL 


CL 


o. 


CL 


Ct 












3 






CD 


CD 


CD 


CD 


CD 


CD 


CD 


CD 


CD 


CD 


CD 


0) 


CD 


CD 


Q£ 


Q£ 








Qi 



















lE 



WO 99/33016 



PCT/US98/27496 







































"C 






























0) 










0 




















£ 




L. 




i _ 








u 




U- 






P 








O 












0 




O 






*o 




0 




*D 




CD 






*D 




■O 






c 




* CO 




■C 






l_ 




C 




c. 






03 
> 
O 








CD 




0 


ega; 


0 




o> 




CD 








rep 


us 


> 
O 


PG 


3 


end 


us 


AO 


1 us 


A 0 




Ck lQ 


-#-» 

2* 

O 

<d 




jntii 


ck to 


O 
CO 


new 


: p 
33 
■P 


3) 
XI 


> 

3> 


0 


ack t 


ck tc 


0 

CO 




«D 
•P 

co 




epai 


*p 
0 


eq 6 


■P 
b) 


issue 


aim 


aim 


aim 


CO 

■P 

CO 


lyb 


CO 
-O 

CO 


JO 
3) 




c: 


+-» 
O 






c 

•r— 1 


a 


0 


0 


0 


c 


ct 


c: 


w 

0 




£ 

.0 

LJ 


Dire 


Need 


Will 


Cpni 


Dire 




File 


File 


File 


Com 


Dire 


Com 


Dire 




1 








CD 


ent 


ent 


























£ 


£ 


£ 












dress 


dress 












ship 


ship 


stiip 






















a>. 


a> 


0) 


















O) 


a> 


eu 


*o 
a> 


+-> 

40 


al 


-•-» 
CO 








ID 
0) 
(0 


pasi 


<: 


< 






CO 


CO 


CO 


J}- 


0 


p 








CO 


CO 






CD 


CO 


co 














c 


c 




I 


E 


E 


£ 




Q. 


a. 




to 


■+■*■ 
to 


...3 


. -> 

S— 


£ 


e 




<D 


CD 


do 


CO 




3 


.3 






0 


:cd 


CD 


? 




O 


O 


0 


Q 


O 


O 


p 




— 1 


-J 




a: 






•b 


X3 


"b 


T3: 


■b 






•to 


■b 


X3 




'is 






;<d 


CD 


0) 


a> 


a> 


0) 


a> 


CD 


CD 


CD 


0) 


a> 




O) 








.«♦"* 




















It-* 






03 


CO 


«° 


GO 


CO 


op 


CO 


CO 


CD 


CO 


CO 


CO 


CO 


CO 














to 
















r-— 




Q) 




*5 






a5 


03 


f c 


e 


I 




CD 




L. 






l_ 


£ 


u 


1. 


: L. 


L. 








U 




on 


01 


CO 


CD 




CO 


CO 


co 


CO 


CO 


co 


CO 


CO 


CO 




c 


c 


. c 






«£ 


C 


c 


c 


c 




c 


c 


c 






EL 




5. 


"25. 


5. 


CL 


EL 


CX 




CX 


1 


CL 


0. 




a 


CL 




CL 


a. 


CL 


, CL 


CL 


CL 


CL 






D. 


CL 






IE 


!E 




x: 


j£ 


/jE 


E 


x: 


x: 




IE 


IE 


IE 






co 




cn 


cn 


CO 


CO 


CO 


to 


CO 


0) 


en 


CD 


to 





o 

u> 



u. 



WO 99/33016 , I PCI7US98/27496 



k_ 

0) 

E 
o 

U 



V/l 

u 

r 

Q. 



O 



W u 



ft in 



o 
(J 

e 



68 

35 



O 

is 

e < 
* m 



o 

L 
0. 



• a 

> Q. 



£ 

o 
z 

□ 



* 9 
k. 

i 

8| 

L. 
0. 







arch 






< 






tf 








-J 






-J 


* 






L 
0 




0) 






SI 

11(1111 

+ 


HI 

gum 

1 





o 



WO 99/33016 



PCT/US98/27496 



T3 

o 

u 

0) 

lac 



| T3 
O 



□ 



> 

S E 
2 !f 



if 



is 



35 



11 

a: 

0 vt 

I 



4 mi 



e 8 



a. ^ 



SI 



a* 

c 

it 

t X 



I! 



u 



It 



-O 
<3 




WO 99/33016 PCTAJS98/27496 




WO 99/33016 PCI7US98/27496 

to, 



o 
E 



4 




















a 




























► 






91 
L 




<N 


as 




(N 


O 

w 










i 

i 

: 


























Januj 


r 




00 


in 


CM 
CM 


a* 










{ 

! 

...-4 

: 
t 

I 


..... 


— ■ 




«... 


— 











.... 






W 

. **• 
- e 




HI •: 


r- 






00 


; 

*r 








i 

i 
i 

I 
i 


























it 






















































M 






ex 




W 


O 
«N 






00 






1 


























- 0 


* 




m 




<n 


<N 




OH 

cs 

N 






























i 






























i 






























C 

o 


W.. 

x« : 






00 




in 

CM 




4l 

O 
4i 
& 






i 

1 

i 






























c 


i 




c 


> 








p> 


Calls ex 






i 

! 

| 


























T 
























< 
























► 






L. 




CO 


in 


N 








Vfl 




































1 

4i 
0 
4i 
Q 




L. 

Lb 






00 


in 

CM 
































Issue 




T 




9 














































L. 

5, 

* 










w 


O 








































z 

















































WO 99/33016 PCT/US98/27496 



>— < 



o 



WO 99/33016 PCT7US98/27496 




4 


| ► 






9 

(A 

a 














istory 
















X 






































9 

** 


















CO 
VI 














L. 
9 




L 














9 

u. 




Ord< 
































Sort 




< 
£ 
u 














>— < 


















-Finished J Today Schedule 




Outstanding Problem 


< 










► 


a 
D 







INTERNATIONAL SEARCH REPORT 



International application No. 
PCT/US98/27496 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC(6) :G06F 17/60, 15/46; G06K 5/00 

US CL : 705/34; 235/380; 364/468.02 
According to International Patent Classification (IPC) or to both national classification and IPC 



FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 
U.S. : 705/34; 235/380; 364/468.02 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 



Electronic data base consulted during the international search (name of data base and, where practicable, search terms used) 
APS 

integration, merging, single, singular, unbroken, uii^ 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category* 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



US 5,621,201 A (LANGHANS et al.) 15 April 1997, col. 16, lines 
14-23 

US 5,311,438 A (SELLERS et al.) 10 May 1994, col. 70, lines 30- 
37, 48-52; co 1. 71, lines 1-7. 



1-79 
1-79 



I | Further documents are listed in the continuation of Box C. Q See patent family annex. 



* Special categories or cited documents: 

'A' document denning the general state of the art which it not coiuidored 

to be of particular relevance 

'E* earlier document published on or after tho international riling date 

'L* document which may throw doubt* on priority claim (a) or which ii 

cited to establish the publication date of another citation or other 
special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or other 

means 

"P" document published prior to the international filing date but later than 
the priority date claimed 



later document published after the international filing date or priority 
date and not in conflict with the application but cited to understand 
the principle or theory underlying the invention 

document of particular relevance; the claimed invention cannot be 
considered novel or cannot be considered to involve an inventive step 
when the document is taken alone 

document of particular relevance; the claimed invention cannot bo 
considered to involve an inventive step when the document is 
combined with one or more other such documents, such combination 
being obvious to a person skilled in the art 

document member of the same patent family 



Date of the actual completion of the international search 



02 MARCH 1999 



Date of mailing of the international search report 



00 APR 1999 



Name and mailing address of the ISA/ US 
Commissioner of Patents and Trademarks 
Box PCT 

Washington, D.C. 20231 
Facsimile No. (703) 305-3230 



Authorized officer 

RAQUEL ALVARE; 
Telephone No. (703) 305-2200 




Form PCT7ISA/210 (second sheet)(July 1992) * 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 

BEST AVAILABLE IMAGES 

Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 

□ LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHIBIT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: 

IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



